View
784
Download
0
Category
Preview:
DESCRIPTION
Citation preview
SCJP 16 (CX-310-065 CX-310-066)
Subject Object Orientation Overloading overriding encapsulation constructor polymorphism is-a has-a relations
Total Questions 66
Prepared by httpwwwjavacertificationsnet
SCJP 60 Object OrientationQuestions Question - 1
What is the output for the below code
1 public class Test 2 public static void main (String[] args) 3 Test t1 = new Test()4 Test t2 = new Test()5 if(t1equals(t2))6 Systemoutprintln(equal)7 else8 Systemoutprintln(Not equal)9 10 11
1Not equal2equal3Compilation fails due to an error on line 5 - equals method not defind in Test class4Compilation fails due to an error on lines 3 and 4
Explanation A is the correct answer
Every class in Java is a subclass of class Object and Object class has equals method In Test class equals method is not implemented equals method of Object class only check for reference so return false in this case t1equals(t1) will return true
Question - 2
What is the output for the below code
1 public class Test 2 public static void main (String[] args) 3 Test t1 = new Test()4 Test t2 = new Test()5 if(t1 instanceof Object)6 Systemoutprintln(equal)7 else8 Systemoutprintln(Not equal)9 10 11
resposta
1Not equal2equal3Compilation fails due to an error on line 5 4Compilation fails due to an error on lines 3 and 4
Explanation B is the correct answer
Every class in Java is a subclass of class Object so every object is instanceof Object
Question - 3
What is the output for the below code
public class A public void printValue() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 bprintName()5 bprintValue()6 7
1Value-A Name-B2Name-B Value-A3Compilation fails due to an error on line 5 4Compilation fails due to an error on lines 4
Explanation B is the correct answer
Class B extended Class A therefore all methods of Class A will be available to class B except private methods
Question - 4
What is the output for the below code
public class A
public void printValue() Systemoutprintln(Value-A)
public class B extends A public void printNameB() Systemoutprintln(Name-B)
public class C extends A public void printNameC() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 newPrint(b)6 newPrint(c) 7 8 public static void newPrint(A a)9 aprintValue()10 11
1Value-A Name-B2Value-A Value-A3Value-A Name-C4Name-B Name-C
Explanation B is the correct answer
Class B extended Class A therefore all methods of Class A will be available to class B except private methods Class C extended Class A therefore all methods of Class A will be available to class C except private methods
Question - 5
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 public void printName()
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation B is the correct answer
This is an example of polymophismWhen someone has an A1 reference that NOT refers to an A1 instance but refers to an A1 subclass instance the caller should be able to invoke printName() on the A1 reference but the actual runtime object (B1 instance) will run its own specific printName() method So printName() method of B1 class executed
Question - 6
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args)
3 A b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation B is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class A and reference variable c is a type of class C but reference variable c is a subtype of A class So it works properly
Question - 7
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)
9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation C is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class B and reference variable c is a type of class C So Compilation fails
Question - 8
What is the output for the below code
public class C
public class D extends C
public class A public C getOBJ() Systemoutprintln(class A - return C) return new C()
public class B extends A public D getOBJ() Systemoutprintln(class B - return D) return new D()
public class Test
public static void main(String args) A a = new B() agetOBJ()
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1Not equal2equal3Compilation fails due to an error on line 5 4Compilation fails due to an error on lines 3 and 4
Explanation B is the correct answer
Every class in Java is a subclass of class Object so every object is instanceof Object
Question - 3
What is the output for the below code
public class A public void printValue() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 bprintName()5 bprintValue()6 7
1Value-A Name-B2Name-B Value-A3Compilation fails due to an error on line 5 4Compilation fails due to an error on lines 4
Explanation B is the correct answer
Class B extended Class A therefore all methods of Class A will be available to class B except private methods
Question - 4
What is the output for the below code
public class A
public void printValue() Systemoutprintln(Value-A)
public class B extends A public void printNameB() Systemoutprintln(Name-B)
public class C extends A public void printNameC() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 newPrint(b)6 newPrint(c) 7 8 public static void newPrint(A a)9 aprintValue()10 11
1Value-A Name-B2Value-A Value-A3Value-A Name-C4Name-B Name-C
Explanation B is the correct answer
Class B extended Class A therefore all methods of Class A will be available to class B except private methods Class C extended Class A therefore all methods of Class A will be available to class C except private methods
Question - 5
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 public void printName()
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation B is the correct answer
This is an example of polymophismWhen someone has an A1 reference that NOT refers to an A1 instance but refers to an A1 subclass instance the caller should be able to invoke printName() on the A1 reference but the actual runtime object (B1 instance) will run its own specific printName() method So printName() method of B1 class executed
Question - 6
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args)
3 A b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation B is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class A and reference variable c is a type of class C but reference variable c is a subtype of A class So it works properly
Question - 7
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)
9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation C is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class B and reference variable c is a type of class C So Compilation fails
Question - 8
What is the output for the below code
public class C
public class D extends C
public class A public C getOBJ() Systemoutprintln(class A - return C) return new C()
public class B extends A public D getOBJ() Systemoutprintln(class B - return D) return new D()
public class Test
public static void main(String args) A a = new B() agetOBJ()
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public void printValue() Systemoutprintln(Value-A)
public class B extends A public void printNameB() Systemoutprintln(Name-B)
public class C extends A public void printNameC() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 newPrint(b)6 newPrint(c) 7 8 public static void newPrint(A a)9 aprintValue()10 11
1Value-A Name-B2Value-A Value-A3Value-A Name-C4Name-B Name-C
Explanation B is the correct answer
Class B extended Class A therefore all methods of Class A will be available to class B except private methods Class C extended Class A therefore all methods of Class A will be available to class C except private methods
Question - 5
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 public void printName()
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation B is the correct answer
This is an example of polymophismWhen someone has an A1 reference that NOT refers to an A1 instance but refers to an A1 subclass instance the caller should be able to invoke printName() on the A1 reference but the actual runtime object (B1 instance) will run its own specific printName() method So printName() method of B1 class executed
Question - 6
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args)
3 A b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation B is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class A and reference variable c is a type of class C but reference variable c is a subtype of A class So it works properly
Question - 7
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)
9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation C is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class B and reference variable c is a type of class C So Compilation fails
Question - 8
What is the output for the below code
public class C
public class D extends C
public class A public C getOBJ() Systemoutprintln(class A - return C) return new C()
public class B extends A public D getOBJ() Systemoutprintln(class B - return D) return new D()
public class Test
public static void main(String args) A a = new B() agetOBJ()
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation B is the correct answer
This is an example of polymophismWhen someone has an A1 reference that NOT refers to an A1 instance but refers to an A1 subclass instance the caller should be able to invoke printName() on the A1 reference but the actual runtime object (B1 instance) will run its own specific printName() method So printName() method of B1 class executed
Question - 6
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args)
3 A b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation B is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class A and reference variable c is a type of class C but reference variable c is a subtype of A class So it works properly
Question - 7
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)
9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation C is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class B and reference variable c is a type of class C So Compilation fails
Question - 8
What is the output for the below code
public class C
public class D extends C
public class A public C getOBJ() Systemoutprintln(class A - return C) return new C()
public class B extends A public D getOBJ() Systemoutprintln(class B - return D) return new D()
public class Test
public static void main(String args) A a = new B() agetOBJ()
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
3 A b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation B is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class A and reference variable c is a type of class C but reference variable c is a subtype of A class So it works properly
Question - 7
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class C extends A public void printName() Systemoutprintln(Name-C)
1 public class Test 2 public static void main (String[] args) 3 B b = new B()4 C c = new C()5 b = c6 newPrint(b) 7 8 public static void newPrint(A a)
9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation C is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class B and reference variable c is a type of class C So Compilation fails
Question - 8
What is the output for the below code
public class C
public class D extends C
public class A public C getOBJ() Systemoutprintln(class A - return C) return new C()
public class B extends A public D getOBJ() Systemoutprintln(class B - return D) return new D()
public class Test
public static void main(String args) A a = new B() agetOBJ()
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
9 aprintName()10 11
1Name-B2Name-C3Compilation fails due to an error on lines 54Compilation fails due to an error on lines 9
Explanation C is the correct answer
Reference variable can refer to any object of the same type as the declared reference OR can refer to any subtype of the declared type Reference variable b is type of class B and reference variable c is a type of class C So Compilation fails
Question - 8
What is the output for the below code
public class C
public class D extends C
public class A public C getOBJ() Systemoutprintln(class A - return C) return new C()
public class B extends A public D getOBJ() Systemoutprintln(class B - return D) return new D()
public class Test
public static void main(String args) A a = new B() agetOBJ()
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1class A - return C2class B - return D3Compilation fails4Compilation succeed but no output
Explanation B is the correct answer
From J2SE 50 onwards return type in the overriding method can be same or subtype of the declared return type of the overridden (superclass) method
Question - 9
What is the output for the below code
public class B public String getCountryName() return USA public StringBuffer getCountryName() StringBuffer sb = new StringBuffer() sbappend(UK) return sb public static void main(String[] args) B b = new B() Systemoutprintln(bgetCountryName()toString())
1USA2Compile with error3UK4Compilation succeed but no output
Explanation B is the correct answer
Compile with error You cannot have two methods in the same class with signatures that only differ by return type
Question - 10
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
What is the output for the below code
public class A1 public void printName() Systemoutprintln(Value-A)
public class B1 extends A1 protected void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) A1 b = new B1() newPrint(b) public static void newPrint(A1 a) aprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails
Explanation D is the correct answer
The access level can not be more restrictive than the overridden methods Compilation fails because of protected method name printName in class B1
Question - 11
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) B b = new B()
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
bprintName()
1Value-A2Name-B3Value-A Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass In this case printName() method a class A is not overriding by printName() method of class B printName() method of class B different method So you can call printName() method of class B
Question - 12
What is the output for the below code
public class A private void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
1 public class Test 2 public static void main (String[] args) 3 A b = new B()4 bprintName()5 6
1Value-A2Compilation fails due to an error on lines 43Name-B4Compilation fails - private methods cant be override
Explanation B is the correct answer
You can not override private method private method is not availabe in subclass printName() method in class A is private so compiler complain about bprintName() The method printName() from the type A is not visible
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Question - 13
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws Exception Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception Exception is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation B is the correct answer
Subclass overriding method must throw checked exceptions that are same or subclass of the exception thrown by superclass method
Question - 14
What is the output for the below code
import javaioFileNotFoundException
public class A public void printName() throws FileNotFoundException Systemoutprintln(Value-A)
public class B extends A public void printName() throws NullPointerException
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Exception NullPointerException is not compatible with throws clause in AprintName()3Name-B4Compilation succeed but no output
Explanation C is the correct answer
The overriding method can throw any unchecked (runtime) exception regardless of exception thrown by overridden method NullPointerException is RuntimeException so compiler not complain
Question - 15
What is the output for the below code
public class A public static void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-This instance method cannot override the static method from A
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a static method Compilation fails-This instance method cannot override the static method from A
Question - 16
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) this() Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Question - 17
What is the output for the below code
public class A public A() Systemoutprintln(A) public A(int i) Systemoutprintln(i)
public class B extends A public B () Systemoutprintln(B) public B (int i) this() Systemoutprintln(i+3)
public class Test public static void main (String[] args) new B(5)
1A B 82A 5 B 83A B 54B 8 A 5
Explanation A is the correct answer
Constructor of class B call their superclass constructor of class A (public A()) which execute first and that constructors can be overloaded Then come to constructor of class B (public B (int i))
Question - 18
What is the output for the below code
public class A public final void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public class B extends A public void printName() Systemoutprintln(Name-B)
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Compilation fails-Cannot override the final method from A3Name-B4Compilation succeed but no output
Explanation B is the correct answer
You cannot override a final method Compilation fails-Cannot override the final method from A
Question - 19
What is the output for the below code
public class A public void printName() Systemoutprintln(Value-A)
public class B extends A public void printName() Systemoutprintln(Name-B) superprintName()
public class Test public static void main (String[] args) throws Exception A a = new B() aprintName()
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1Value-A2Name-B Value-A3Name-B4Value-A Name-B
Explanation B is the correct answer
superprintName() calls printName() method of class A
Question - 20
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A b = new B()4 bprintValue()5 6
1Value-B2Compilation fails due to an error on lines 43Name-B4Value-B Name-B
Explanation B is the correct answer
You are trying to use that A reference variable to invoke a method that only class B has The method printValue() is undefined for the type A So compiler complain
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Question - 21
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 A a = new A()4 B b = (B)a5 bprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation D is the correct answer
javalangClassCastException A cannot be cast to B You can cast subclass to superclass but not superclass to subclassupcast is ok You can do B b = new B() A a = (A)b
Question - 22
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public class B extends A public void printName() Systemoutprintln(Name-B) public void printValue() Systemoutprintln(Value-B)
1 public class Test 2 public static void main (String[] args)3 B b = new B()4 A a = (A)b5 aprintName()6 7
1Value-B2Compilation fails due to an error on lines 43Name-B4Compilation succeed but Runtime Exception
Explanation C is the correct answer
You can cast subclass to superclass but not superclass to subclassupcast is ok Compile clean and output Name-B
Question - 23
Which of the following statement is true
1A class can implement more than one interface2An interface can extend another interface3All variables defined in an interface implicitly public static and final4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 24
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
What is the output for the below code
1 public interface InfA 2 protected String getName()3
public class Test implements InfA public String getName() return test-name public static void main (String[] args) Test t = new Test() Systemoutprintln(tgetName())
1test-name2Compilation fails due to an error on lines 23Compilation fails due to an error on lines 14Compilation succeed but Runtime Exception
Explanation B is the correct answer
Illegal modifier for the interface method InfAgetName() only public and abstract are permitted
Question - 25
What is the output for the below code
public class A public void printName() Systemoutprintln(Name-A)
1 public class B extends A 2 public String printName()3 Systemoutprintln(Name-B)4 return null5 6
public class Test public static void main (String[] args) A a = new B() aprintName()
1Name-B
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
2Compilation fails due to an error on lines 23Name-A4Compilation fails due to an error on lines 4
Explanation B is the correct answer
printName() method of class A and printName() method of class B has different return type So printName() method of class B does not overriding printName() method of class A But class B extends A so printName() method of class A is available in class B So compiler complain about the same method name Method overloading does not consider return types
Question - 26
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D)
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation B is the correct answer
Since there is already a constructor in this class (public D(int iint j)) the compiler wont supply a default constructor If you want a no-argument constructor to overload the with-arguments version you already have you have to define it by yourself The constructor D() is undefined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D() then
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
the above code will work If no constructor into your class a default constructor will be automatically generated by the compiler
Question - 27
What is the output for the below code
public class D int i int j public D(int iint j) thisi=i thisj=j public void printName() Systemoutprintln(Name-D) public D()
1 public class Test 2 public static void main (String[] args)3 D d = new D()4 dprintName()5 6 7
1Name-D2Compilation fails due to an error on lines 33Compilation fails due to an error on lines 44Compilation succeed but no output
Explanation A is the correct answer
The constructor D() is defined in class D If you define explicit constructor then default constructor will not be available You have to define explicitly like public D()
Question - 28
Which of the following statement is true about constructor
1The constructor name must match the name of the class2Constructors must not have a return type
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
3The default constructor is always a no arguments constructor4All of the above statements are true
Explanation D is the correct answer
All of the above statements are true
Question - 29
What is the output for the below code
1 public class A 2 int i3 public A(int i)4 thisi=i5 6 public void printName()7 Systemoutprintln(Name-A) 8 9
10 public class C extends A11
12 public class Test 13 public static void main (String[] args)14 A c = new C()15 cprintName() 16 17
1Name-A2Compilation fails due to an error on lines 103Compilation fails due to an error on lines 144Compilation fails due to an error on lines 15
Explanation B is the correct answer
Implicit super constructor A() is undefined for default constructor Must define an explicit constructor Every constructor invokes the constructor of its superclass implicitly In this case constructor of class A is overloaded So need to call explicitly from subclass constructor You have to call superclass constructor explicitly public class C extends A public C() super(7)
Question - 30
What is the output for the below code
public class A
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public A() Systemoutprintln(A)
public class B extends A public B() Systemoutprintln(B)
public class C extends B public C() Systemoutprintln(C)
public class Test public static void main (String[] args) C c = new C()
1A B C2C B A3C A B4Compilation fails
Explanation A is the correct answer
Every constructor invokes the constructor of its superclass implicitly Superclass constructor executes first then subclass constructor
Question - 31
What is the output for the below code
public class A public A(int i) Systemoutprintln(i)
1 public class B extends A 2 public B()3 super(6)4 this()5 6
public class Test public static void main (String[] args)
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
B b = new B()
16203Compilation fails due to an error on lines 34Compilation fails due to an error on lines 4
Explanation D is the correct answer
A constructor can NOT have both super() and this() Because each of those calls must be the first statement in a constructor you can NOT use both in the same constructor
Question - 32
What is the output for the below code
1 public class A 2 public A()3 this(8)4 5 public A(int i)6 this() 7 8
public class Test public static void main (String[] args) A a = new A()
18203Compilation fails due to an error on lines 14Compilation fails due to an error on lines 3
Explanation D is the correct answer
This is Recursive constructor invocation from both the constructor so compiler complain
Question - 33
What is the output for the below code
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1 public class Test 2 static int count3 public Test()4 count = count +1 5 6 public static void main(String argv[])7 new Test()8 new Test()9 new Test()10 Systemoutprintln(count) 11 12
1320314Compilation fails due to an error on lines 2
Explanation A is the correct answer
static variable count set to zero when class Test is loaded static variables are related to class not instance so count increases on every new Test()
Question - 34
public class A public void test1() Systemoutprintln(test1)
public class B extends A public void test2() Systemoutprintln(test2)
1 public class Test 2 public static void main (String[] args)3 A a = new A() 4 A b = new B() 5 B b1 = new B()6 insert code here7 8
Which of the following inserted at line 6 will compile and print test2
1((B)b)test2()2(B)btest2()3btest2()4atest2()
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Explanation A is the correct answer
((B)b)test2() is proper cast test2() method is in class B so need to cast b then only test2() is accessible (B)btest2() is not proper cast without the second set of parentheses the compiler thinks it is an incomplete statement
Question - 35
What is the output for the below code
public class A static String str = protected A() Systemoutprintln(str + A)
public class B extends A private B () Systemoutprintln(str + B)
1 public class Test extends A2 private Test()3 Systemoutprintln(str + Test)4 5 public static void main (String[] args)6 new Test()7 Systemoutprintln(str)8 9
1A Test2A B Test3Compilation fails due to an error on lines 64Compilation fails due to an error on lines 2
Explanation A is the correct answer
Test class extends class A and there is no attempt to create class B object so private constructor in class B is not called private constructor in class Test is okay You can create object from the class where private constructor present but you cant from outside of the class
Question - 36
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class outputtest public static void main(String[] args) A b = new B() btest1()
What is the output
1test1 A2test1 B3Not complile because test1() method in class A is not visible4None of the above
Explanation C is the correct answer
Not complile because test1() method in class A is not private so it is not visible
Question - 37
public class A private void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args) B b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
This is not related to superclass B class object calls its own method so it compile and output normally
Question - 38
public class A public void test1() Systemoutprintln(test1 A)
public class B extends Apublic void test1() Systemoutprintln(test1 B)
public class Testpublic static void main(String[] args)A b = new B() btest1()
What is the output
1test1 B2test1 A3Not complile because test1() method in class A is not visible4None of the above
Explanation A is the correct answer
Superclass reference of subclass point to subclass method and superclass variables
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Question - 39
What is the output of the below code class c1public static void main(String a[])c1 ob1=new c1()Object ob2=ob1Systemoutprintln(ob2 instanceof Object)Systemoutprintln(ob2 instanceof c1)
1Prints truefalse2Print falsetrue3Prints truetrue4compile time error
Explanation C is the correct answer
instanceof operator checks for instance related to class or not
Question - 40
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D() works
1It compile without any error2It compile with error
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
3Cant say4None of the above
Explanation B is the correct answer
C c = new D() NOT COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 41
public class C public C()
public class D extends C
public D(int i) Systemoutprintln(tt) public D(int i int j) Systemoutprintln(tt)
Is C c = new D(8) works
1It compile without any error2It compile with error3Cant say4None of the above
Explanation A is the correct answer
C c = new D(8) COMPILE because D dont have default constructor If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 42
public class C
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public C(int i)
public class D extends C public D()
is this code compile without error
1yes compile without error2No compile with error3Runtime Exception4None of the above
Explanation B is the correct answer
We need to invoke Explicitly super constructor()
Question - 43
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public int doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
method are reference to sub class and variables are reference to superclass
Question - 44
public class SuperClass public int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() Return type of the method doIt() should be int
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Question - 45
public class SuperClass private int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt() Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The method doIt() from the type SuperClass is not visible
Question - 46
public class SuperClass public final int doIt() Systemoutprintln(super doIt()) return 1
public class SubClass extends SuperClass
public long doIt()
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Systemoutprintln(subclas doIt()) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt() What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
Cannot override the final method from SuperClass
Question - 47
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws Exception String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() sbdoIt(hello 3)
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1Overridden hello (String Integer[])2hello (String Integer[])3Complile time error4None of the above
Explanation C is the correct answer
Unhandled exception type Exception
Question - 48
What will be the result of compiling the following code
public class SuperClass public int doIt(String str Integer data)throws ArrayIndexOutOfBoundsException String signature = (String Integer[]) Systemoutprintln(str + + signature) return 1
public class SubClass extends SuperClass
public int doIt(String str Integer data) throws Exception String signature = (String Integer[]) Systemoutprintln(Overridden + str + + signature) return 0 public static void main(String args) SuperClass sb = new SubClass() try sbdoIt(hello 3) catch(Exception e)
1Overridden hello (String Integer[])2hello (String Integer[])3The code throws an Exception at Runtime4Compile with error
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Explanation D is the correct answer
Exception Exception is not compatible with throws clause in SuperClassdoIt(String Integer[]) The same exception or subclass of that exception is allowed
Question - 49
public class SuperClass public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public List doIt() List lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation C is the correct answer
The return type is incompatible with SuperClassdoIt() subtype return is eligible in jdk 15 for overidden method but not super type return super class method return ArrayList so subclass overriden method should return same or sub type of ArrayList
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Question - 50
public class SuperClass public List doIt() List lst = new ArrayList() Systemoutprintln(super doIt()) return lst
public class SubClass extends SuperClass
public ArrayList doIt() ArrayList lst = new ArrayList() Systemoutprintln(subclas doIt()) return lst public static void main(String args) SuperClass sb = new SubClass() sbdoIt()
What is the output
1subclas doIt()2super doIt()3Compile with error4None of the above
Explanation A is the correct answer
subtype return is eligible in jdk 15 for overidden method but not super type return super class method return List so subclass overriden method should return same or sub type of List
Question - 51
class Cint ipublic static void main (String[] args) int i 1 private int a = 1 2 protected int b = 1 3
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
public int c = 1 4 Systemoutprintln(a+b+c) 5
1compiletime error at lines 123452compiletime error at lines 23453compiletime error at lines 2344prints 3
Explanation B is the correct answer
The access modifiers public protected and private can not be applied to variables declared inside methods
Question - 52
Which variables can an inner class access from the class which encapsulates it
1All final variables2All instance variables3Only final instance variables4All of the above
Explanation D is the correct answer
Inner classes have access to all variables declared within the encapsulating class
Question - 53
class c1 public void m1() Systemoutprintln(m1 method in C1 class) class c2 public c1 m1() return new c1() public void m1() Systemoutprintln(m1 mehod in anonymous class) public static void main(String a[])
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
c1 ob1 =new c2()m1() ob1m1()
1prints m1 method in C1 class2prints m1 method in anonumous class3compile time error4Runtime error
Explanation B is the correct answer
the anonymous class overrides the m1 method in c1so according to the dynamic dispatch the m1 method in the anonymous is called
Question - 54
abstract class vehicleabstract public void speed()class car extends vehiclepublic static void main (String args[]) vehicle ob1 ob1=new car() 1
1compiletime error at line 12forces the class car to be declared as abstract3Runtime Exception4None of the above
Explanation B is the correct answer
Abstract method should be overriden otherwise Subclass should be abstract
Question - 55
abstract class C1public void m1() 1abstract class C2 public void m2() 2
1compile time error at line12compile time error at line23The code compiles fine
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
4None of the above
Explanation C is the correct answer
since the class C2 is abstract it can contain abstract methods
Question - 56
class basebase(int c) Systemoutprintln(base)class Super extends base Super() Systemoutprintln(super) public static void main(String [] a) base b1=new Super()
1compile time error2runtime exceptione3the code compiles and runs fine4None of the above
Explanation A is the correct answer
If super class has different constructor other then default then in the sub class you cant use default constructor
Question - 57
class C1public void m1() 1class C2 extends C1 2private void m1()
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
1compile time error at line12compile time error at line23Runtime exception4None of the above
Explanation B is the correct answer
extending to assign weaker access not allowed Overridden method should be more public
Question - 58
class C1static interface I static class C2
public static void main(String a[])C1IC2 ob1=new C1IC2()Systemoutprintln(object created)
1prints object created2Compile time error3Runtime Excepion4None of the above
Explanation A is the correct answer
A static interface or class can contain static membersStatic members can be accessed without instantiating the particular class
Question - 59
class C1 static class C2 static int i1 public static void main(String a[])
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Systemoutprintln(C1C2i1)
1prints 02Compile time error3Runtime exception4None of the above
Explanation A is the correct answer
static members can be accessed without instantiating the particular class
Question - 60
What will happen when you attempt to compile and run the following code
class Baseprotected int i = 99public class Abprivate int i=1public static void main(String argv[])Ab a = new Ab()ahallow()
abstract void hallow() Systemoutprintln(Claines +i)
1Compile time error2Compilation and output of Claines 993Compilation and output of Claines 14Compilation and not output at runtime
Explanation A is the correct answer
Abstract and native methods cant have a body void hallow() abstract void hallow()
Question - 61
public class A extends Integerpublic static void main(Sring[] args)Systemoutprintln(Hello)
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
What is the output
1Hello2Compile Error3Runtime4None of the above
Explanation B is the correct answer
final class cant be extended Integer is final class
Question - 62
which statement is correct
1A nested class is any class whose declaration occurs within the body of another class or interface2A top level class is a class that is not a nested class3A top level class can be private4none of the above
Explanation A and B is the correct answer
A nested class is any class whose declaration occurs within the body of another class or interface A top level class is a class that is not a nested class
Question - 63
Constructor declarations can be include the access modifiers
1public2protected3private4All of the above
Explanation D is the correct answer
constructor declarations may include the access modifiers public protected or private
Question - 64
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
private class B public static void main(String[] args) Systemoutprintln(DD) B b = new B()
What is the output
1DD2Compile Error3Runtime Exception4None of the above
Explanation B is the correct answer
Only public abstract and final is permitted for class modifier
Question - 65
public class Point int x = 1 y = 1 abstract void alert()
Is the code compile without error
1compile without error2compile with error because class should be abstract3Cant say4None of the above
Explanation B is the correct answer
If there is any abstract method in a class then the class should be abstract
Question - 66
abstract class Point int x = 1 y = 1 abstract void alert()
public class Apublic static void main(String[] args)Point p = new Point()
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
What is the output
1compile without error2compile with error3Cant say4None of the above
Explanation B is the correct answer
abstract class cant be instantiated
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Modeling Web Business Processes with OO-H and UWE1
NORA KOCH AND ANDREAS KRAUS Ludwig-Maximilians-Universitaumlt Muumlnchen
Germany
CRISTINA CACHERO AND SANTIAGO MELIAgrave Universidad de Alicante Spain
________________________________________________________________________ Business processes regarded as heavy-weighted flows of control consisting of activities and transitions pay an increasingly important role in Web applications In order to address these business processes Web methodologies are evolving to support its definition and integration with the Web specific aspects of content navigation and presentation This paper presents the model support provided for this kind of processes by both OO-H and UWE For this support both approaches use UML use cases and activity diagrams and provide appropriate modeling extensions Additionally the connection mechanisms between the navigation and the process specific modeling elements are discussed As a representative example to illustrate our approach we present the requirements analysis and design models for the amazoncom Website with focus on the checkout process Our approach includes requirements and analysis models shared by OO-H and UWE and provides the basis on which each method applies its particular design notation Categories and Subject Descriptors H54 [Information Interfaces and Presentation] HypertextHypermedia ndash Architecture Navigation User Issues D22 [Software Engineering] Design Tools and Techniques ndash Object-oriented Design Methods D21 [Software Engineering] Requirements Specification ndash Methodologies I65 [Computing Methodologies] Simulation and Modeling ndash Model Development
General Terms Design Experimentation Human Factors
Additional Key Words and Phrases Web Engineering UML Visual Modeling Process Modeling UML Profile
________________________________________________________________________
1 INTRODUCTION
Business processes regarded as heavy-weighted flows of control consisting of activities and transitions [UML 2003] have always paid an important role in software development methods to the point that many process proposals include the definition of an explicit view (the process view) in order to address their complexity However such processes have been only tangentially tackled in most existing Web Application modeling approaches [Retschitzegger amp Schwinger 2000] This reality is partly due to the fact that most of these methods were born with the aim of successfully modeling Information Systems (IS) [Baresi et al 2001 Schwabe et al 2001 Ceri et al 2002 De Troyer amp Casteleyn 2001 Gomez et al 2001 Koch amp Kraus 2002] which lsquostore retrieve
1 This work has been partially supported by the European Union within the IST project AGILE ndash Architectures for Mobility (IST-2001-32747) the German BMBF-project GLOWA-Danube and the Spain Ministry of Science and Technology project number TIC2001-3530-C02-02 Authors addresses Nora Koch and Andreas Kraus Ludwig-Maximilians-Universitaumlt Muumlnchen Germany httpwwwpstinformatikuni-muenchende kochnkrausainformatikuni-muenchende Cristina Cachero and Santiago Meliaacute Universidad de Alicante Espantildea httpwwwuaes ccacherosantidlsiuaes
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
transform and present information to users [They] Handle large amounts of data with complex relationships which are stored in relational or object databasesrsquo [Korthaus 1998] Therefore Web modeling approaches have intensively worked on (1) the definition of suitable constructs to address the user navigation through the domain information space and (2) the inclusion of mechanisms to model the change in such information space through the invocation of synchronous retrieval and update operations In contrast requirements posed on modern Web applications imply to regard them not only as Information Systems but also as Business Systems that is applications centered on goals resources rules and mainly the actual work in the business (business processes) Workflow management systems which have proven successful for the definition and control of these processes fall short however when faced to the problem of defining rich business-enabled Web interfaces that aware of the underlying workflow support and guide the user through it preserving at the same time the hypertext flexibility
The hypermedia community conscious of this gap has been working for some time on the extension of Web modeling methods (which are specially suited to deal with the complexity of Web interfaces) with new mechanisms that permit the definition and integration of lightweight business processes with the rest of the views This extension may be done following at least two different approaches on one hand traditional content navigation andor presentation models may be enriched to capture this workflow Examples in this sense include Araneus2 [Atzeni amp Parente 2001] which defines the mechanisms to allow the grouping of activities into phases Wisdom [Nunes amp Cunha 2000] which proposes a UML extension that includes the use of a set of stereotyped classes or WebML [Brambilla et al 2002] which enriches the data and the hypertext models to define lightweight web-enabled workflows On the other hand additional models may be defined and its connection with the pre-existing content hypertext andor presentation views established This has been the approach jointly followed by UWE and OO-H as we will present in this paper
Our aim in this paper has been therefore to find a common set of modeling concepts that suffices to define sound non-trivial business processes and that could be equally useful in other existing methodologies In order to define the necessary constructs and modeling activities we have decided to adhere to well known object-oriented standards namely to the semantics and notation provided by UML Using UML to model business processes is not new authors like [Nunes amp Cunha 2000 Markopoulos 2000] have already acknowledged its feasibility and excellence From the set of modeling techniques provided by the UML the activity diagram is the most suitable mechanism to model the business workflow and so has been adopted by both OO-H and UWE to define the different processes In this diagram activity states represent the process steps and transitions capture the process flow including forks and joins to express sets of activities that can be processed in arbitrary order
In order to reach our goal this work is organized as follows Sections 2 and 3 present the analysis steps equal for both methodologies Section 4 and Section 5 describe the design steps for OO-H and UWE respectively Last Section 6 outlines conclusions while Section 7 proposes future lines of research In order to better illustrate the whole approach a simplified view of the well-known Amazon checkout process (httpwwwamazoncom) is going to be employed all along the paper
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
2 THE ROLE OF BUSINESS PROCESSES IN REQUIREMENT ANALYSIS
The inclusion of a business process in any Web modeling approach affects every stage of development from requirements analysis to implementation Regarding requirements analysis whose goal is the elicitation specification and validation of the user and customer needs this activity includes the detection of both functional and non-functional requirements both of which may get affected by process concerns
Although there is a lack of a standardized process supporting requirements analysis best practices in the development of general software applications provide a set of techniques A recent comparative study [Escalona amp Koch 2003] about requirements engineering techniques for the development of Web applications showed that use case modeling is the most popular technique proposed for the specification of requirements while interviewing is the most used technique for the capture of those requirements These results are not surprising traditional software development requires interviewing as an intuitive and widely used procedure to guide a ldquoconversation with a purposerdquo [Kahn amp Cannell 1957] and use cases are a well known approach for graphical representation and description of requirements suggested by [Jacobson et al 1992] Use case modeling is a powerful formalism to express functional requirements of business intensive ndash Web or non-Web ndash applications
In this sense OO-H and UWE are object-oriented approaches (partially and completely based on UML respectively) and both of them include the use case modeling technique to gather the requirements of Web applications To define a use case model the first step is to identify actors and the corresponding use cases of the application Such a use case model usually includes a use case diagram which is usually enough to describe the functionality of simple systems such as of Web information systems On the other hand Web applications including business processes require a more detailed description of these ndash more complex ndash sequences of actions In order to address this additional complexity as it is shown in the next section both approaches propose the use of UML activity diagrams
In our running example we have identified two actors that play a relevant role in the checkout process the NonRegisteredUser and the Customer The non-registered user can ndash among other activities ndash search and select products add products to the shopping cart and login into the Amazon Web application The Customer inherits from the NonRegisteredUser and is allowed among other things (after logged-in) to start the checkout process
Fig 1 presents a partial view of the use case diagram corresponding to the Amazon Web application For the sake of simplicity in this diagram we have centered on the use cases that are directly related to the selection of items and the checkout process therefore ignoring others such as just to name a few AddToWishList CheckOrder or ReturnItems which are however also relevant tasks from the user point of view
In this diagram we can observe how a NonRegisteredUser may select product items Such selection may be performed using a system search capability which is modeled by means of an inheritance relationship between the use cases SelectProductItems and SearchProductItems Also this user may decide to add any selected product to his
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
shopping cart This fact is modeled by means of an laquoextendraquo dependency between the use case AddToShoppingCart and the SelectProductItems use case
AddToShoppingCart
Checkout SendInvoiceltltincludegtgt
Customer
SelectProductItemsltltnavigationgtgt
ltltextendgtgt
SearchProductItemsltltnavigationgtgt
SignIn
ltltextendgtgt
ViewCartltltnavigationgtgtNonRegisteredUser
Fig 1 Use Case Diagram of the Checkout Process in wwwamazoncom
At any time the user may decide to ViewCart in order to check the items included so far in his shopping basket Also he could decide to personalize her view for what he would have to SignIn Furthermore only a signed-in user may proceed to checkout This situation is again modeled by means of an laquoextendraquo dependency between the use cases SigIn and Checkout The completion of the checkout process implies the sending of a notification with the invoice associated with the purchase We have modeled this action as a use case that is related (laquoincluderaquo dependency) to the Checkout use case The Customer may also wish to be sent an additional invoice at any time after the purchase in Fig 1 this fact is captured by means of an association between the actor Customer and the SendInvoice use case
If we now analyze the inner flow of control of each defined use case in the context of the Amazon Web application we may note how some flows are trivial from the business point of view as they only express navigation activities For this kind of use cases we propose the use of a laquonavigationraquo stereotype as defined in [Baresi et al 2001] Others on the contrary imply a complex flow of control and require further refinements as we will show next
3 ANALYSIS PHASE IN PROCESS-AWARE WEB APPLICA-TIONS
Once the requirements have been clearly stated both in OO-H and UWE the next step consists on the analysis of the problem domain This analysis phase has traditionally involved in both methods the definition of a conceptual model reflecting the domain structure of the problem This model however does not provide the mechanisms to specify process concerns That is the reason why we have included a new model the
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
process model that enriches this analysis phase Next we will show how these models can be applied to our running example
31 CONCEPTUAL MODEL
The definition of a conceptual model by means of a UML class diagram is a common feature in most Web modeling approaches including UWE and OO-H Back to our example we have defined a common conceptual model materialized in a UML class diagram that is depicted in Fig 2
UserModelConceptualModel
DVD
Book
CD
OrderItem
quantity
CustomernamecreditCard
ShoppingCart
add()checkout()
011
Addressstreetzip-codecountry1
+deliveryAddress
01
ShoppingCartItem
quantity
1
Order
orderIDinvoiceNumber
sendInvoice()
1
1
+invoiceAddress
1
Productnameprice 1
Fig 2 Conceptual Model of the Checkout Process in wwwamazoncom
This class diagram is made up of two packages the User Model and the Conceptual Model The first one includes the structures directly related to the individual user such as the ShoppingCart or the different Addresses provided by each Customer The Conceptual Model on the other hand maintains information related to domain objects such as Products and Orders Note how this diagram is a simplification of the actual Amazon domain model and reflects only a possible subset of constructs that are needed to support the checkout process In this diagram we can observe how a customer (which may be anonymous before logging-in in the system) has a ShoppingCart which is made-up of ShoppingCartItems (each one associated with a Product which may be a Book a DVD or a CD just to name a few) On the other hand each customer has a set of predefined Addresses that once the order has been created are used both to send the different items and to set the invoice address When the customer decides to checkout the system creates a new Order and converts the ShoppingCartItems into OrderItems When the order is finally placed an invoiceNumber is associated to the order
The conceptual model is not well suited to provide information on the underlying business processes that drive the user actions through the application For this reason OO-H and UWE have included a process model that is outlined in the next two sections
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
32 PROCESS MODEL Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field Different UML notations have already been proposed for process modeling Wisdom [Nunes amp Cunha 2000] is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive Markopoulus [Markopoulos 2000] instead makes two different proposals an UML extension of use cases and another one based on statecharts and activity diagrams Following this last trend we have opted to use activity diagrams due to their frequency of use and their flexibility to model flows
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are actions or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or completion of the subactivities in the source states The entire activity diagram is attached (through the model) to a UML classifier such as a use case or to a package or to the implementation of an operation [UML 2003] The UML modeling elements for a process model are activities transitions and branches Activities represent atomic actions of the process and they are connected with each other by transitions (represented by solid arrows) and branches (represented by diamond icons) The branch conditions govern the flow of control and in the analysis process model they can be expressed in natural language
As stated before both OO-H and UWE use activity diagrams to complement the domain model and define the inner flow of control of non trivial use cases In Fig 3 an activity diagram representing the simplified flow of control of the Amazon Checkout process (depicted as a non-navigational use case in Fig 1) is presented
[ error ]AddNewCustomer
SignIn[ error ]
[ newCustomer ]
SetOptions
[ returningCustomer ]
PlaceOrder
exit delete Items of ShoppingCart
SendInvoice
newCustomer Customer
newOrder Order
SetPassword
[ newCustomer ]
[ returningCustomer ]
[ change ]
Fig 3 Process Model of the Checkout Process in wwwamazoncom
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
In this diagram we can observe how a SignIn subactivity starts the process Next depending on whether the user is new in the system or not he can be added to the system or directly driven to the SetOptions subactivity state that permits the user to establish every purchase option (see ) Once this activities has been completed the user may set his password (only if he is a new customer) place the order and be sent an invoice with the purchase details
Subactivity states as shown in the diagram of Fig 3 express the hierarchical decomposition of a process A subactivity state invokes another activity diagram When a subactivity state is entered the nested activity graph is executed A single activity graph may be invoked by many subactivity states meaning that activity diagrams can be (re-)used within the context of different processes and sub processes (ie subactivities) In our example Fig 4 shows the flow of control of the SetOptions subactivity state represented by a UML activity diagram This diagram includes activities for the user to enter shipping and payment options wrapping options and confirm the cart items before placing the order In the checkout process only options not already set before eg in previous checkouts or those that the user explicitly wants to change are triggered in the process context
ConfirmItems SetWrapOptions
[ not set or change ][ not set or change ]
SetShippingOptions
[ not set or change ]
SetPaymentOptions
[ not set or change ]
Fig 4 Activity Diagram of the SetOptions Process in wwwamazoncom
In Fig 3 we can also observe how the use and extend dependencies defined in the use case diagram of Fig 1 influence the flow of control of the process and are materialized in the inclusion of complementary activities (see eg SendInvoice) and subactivity states (eg SignIn) that as suggested by such dependencies play a role in the definition of the checkout process
Finally the activity diagram associated with a given Web-aware business process can also be enriched with object flows indicating objects that are relevant at analysis level as input and output to crucial activities In the example a new Customer is created as result of the AddNewCustomer activity and a new Order object is created as result of the PlaceOrder activity
Once this analysis model has been defined at least two approaches can be followed
bull The definition of a navigation model that is driven by a (refined) process flow model This tight integration between process and navigation expresses the
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
interplay between the user interface design and the steps inferred from the process definition
bull The definition of a navigation model that is enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process design view
Next we will show how OO-H and UWE each implements one of these approaches and how in spite of this fact analysis models are still fully reusable and a common ground for discussion
4 DESIGN OF WEB BUSINESS PROCESS WITH OO-H
OO-H [Cachero 2003 Gomez et al 2001] is a generic approach partially based on the Object Oriented paradigm that provides the designer with the semantics and notation necessary for the development of personalized Web-based interfaces Like many other approaches the OO-H modeling process is driven by the set of identified user requirements and explicitly supports the definition of different user interfaces depending on the actor that is accessing the application The whole method is supported by the Case tool VisualWADE a modeling environment that includes a set of model compilers to provide automatic code generation capabilities
From the six complementary views included in OO-H (requirement conceptual process navigation presentation and architectural) in this article we will center on the process view This process view is based as stated above on a set of activity diagrams that supplement the information contained in the domain model In order to make this connection between both models explicit both class and activity diagrams are refined during the design phase and the correspondence between the process constructs and the domain constructs is set On this refined process view a set of mapping rules can be applied in order to get a default navigation view and assure the traceability between both models as will be explained in section 42
41 PROCESS MODEL REFINEMENT OO-H bases the process refinement on the concept of service regarded as an interface whose purpose is collect a set of operations that constitute a coherent service offered by classifiers and so provide a way to partition and characterize groups of operations [UML 2003]
Services in OO-H can be classified according to several orthogonal characteristics among which we outstand (1) synchronicity (2) activating agent (3) granularity (number of operations supporting the service) and (4) transactionality [Cachero 2003] OO-H centers on synchronous user-activated services Inside this group OO-H is well suited to provide an arbitrary complex interface to single (either transactional or not) services where by single we mean services supported by exactly one underlying class operation That is the case of Create Delete and Update operations which are at the core of typical single transactional (ACID) services
On the other hand the definition of an interface for a compound service which involves more than one domain operation presents special challenges from the user interface
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
modeling point of view In this kind of services the user interface is responsible for guiding the user through the different domain operations following a predefined flow of control which may involve both activity and information dependencies A checkout service such as the one included in Amazon is from the OO-H point of view a compound non-transactional service For this service a possible activity diagram representing the system flow of control has been already presented in Fig 3
In order to further refine the analysis process view we must take into account detailed class properties A new class diagram with a more exhaustive list of attributes and methods is shown in Fig 5 Note how this diagram can be regarded as a possible evolution of the one presented in Fig 2
Book CD DVD
Product ShoppingCartItem
Order
orderID
new()
ShoppingCart
ID
Customer
Address
11
11
11
11
pNameprice
quantity
cName
streetzip-codecountry
invoiceNumber
addItem()checkout() login()
emailAddresspasswd
setShippingAddress()setBillingAddress()setPaymentOptions()
shippingSpeed
placeOrder()
OrderItem
quantity 11
new()setPasswd()
confirmItem()
setWrappingOptions()
+
+
1 01
sendInvoice()
deleteItems()
Fig 5 OO-H Refined Class Diagram of the Checkout Process in wwwamazoncom
Taking into account the underlying operations it is possible to construct a more detailed activity diagram such as the one presented in Fig 6 In this figure we observe several examples of refinements allowed in OO-H at this level of abstraction
bull Some subactivity states may be redefined as call states implying that a single operation (at most) gives them support That is the case of the SignIn subactivity state (see Fig 3) that has been now redefined as a call state
bull Some call states may be merged under a common subactivity state This feature is specially useful when a transaction is detected which involves several call states In our example we have considered that PlaceOrder and SendInvoice are related activities (in the checkout process the invoice is automatically sent after the order has been placed) and that an error while sending the invoice implies that the order cannot be placed because the user would lack the necessary notification Therefore we have defined a transactional subactivity state that includes both call states (see Fig 6)
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
bull Call states may be complemented (if necessary) with information regarding the domain operation that gives them support in a do section For example the transactional activity SetPasswd() states in the refined activity diagram that this activity is supported by the operation setPasswd(in passwdString) which belongs to the Customer class Note how this fact could also have been modelled by means of swimlanes added to the diagram
bull A new laquotransactionalraquo stereotype must be applied to the different activities This stereotype reflects the transactional character of both call states and subactivity states A transactional activitysubactivity state presents the classical ACID properties Furthermore transactional subactivity states imply that every underlying activity or subactivity state belongs to the same transaction On the contrary a non-transactional subactivity state does not pose any requirement over the elements included Back to our example the SignIn activity has been defined as non-transactional In our approach this fact implies that the activity does not need logic support as it might be modelled with the aid of filters and navigation constructs as we will show in section 42
SignInltltnonTransactionalgtgt
do Customerlogin()
AddNewCustomerltlttransactionalgtgt
do Customernew(eMail)
SetOptionsltltnonTransactionalgtgt
entry Ordernew()
PlaceOrderltlttransactionalgtgt
exit ShoppingCartdeleteItems()
SetPasswdltlttransactionalgtgt
do CustomersetPasswd(passwd)
[ newCustomer ]
[ newCustomer ]
[ Error ]
[ returningCustomer ]
[ Error ]
[ returningCustomer ]
Fig 6 OO-H Refined Activity Diagram of the Checkout Process in wwwamazoncom
For the sake of simplicity in Fig 6 we have hidden other possible refinements such as for example the set of OCL guard conditions that may be associated with the transitions the OCL formulae that may be associated to non-transactional activities or the detailed flow of objects among activities andor subactivity states which would also be relevant at this stage of the model and from which it would be possible to infer certain parameter dependencies during the invocation of the underlying methods if necessary
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
42 DEFAULT NAVIGATION MODEL As we have stated before OO-H redefines call states so that they can be mapped to underlying domain constructs In order to support this mapping the UML metamodel must be conservatively extended to capture this connection between OO-H activities (a specialization of the UML activity construct) and conceptual operations andor classes The reason for this connection is that as we will see next in this way it is possible to automatically generate a default navigation view that not only speeds up the development cycle but also assures the interface guidance and support to this process
The navigation model in OO-H is defined by means of a Navigation Access Diagram (NAD) This diagram is made up of collections (depicted as an inverted triangle and which capture in OO-H the menu concept) navigation targets (navigation subsystems depicted with a package symbol) navigation classes (views on conceptual classes depicted with the class symbol) and navigation links (which describe the paths the user may follow through the system and that are depicted with the arrow symbol) Navigational links being a central construct in OO-H and the core of the navigation view have several relevant characteristics associated
bull Type It can be set to (1) requirement link which determines the beginning of the user navigation through the diagram (2) traversal link which defines navigation paths between information structures or (3) service link which provides an arbitrarily complex user interface to assign values to the underlying in operation parameters andor define the visualization of the operation results (out parameters)
bull Activating Agent can be set to user (depicted as a solid arrow) or system (depicted as a dotted arrow)
bull Navigation effect can be set to origin (depicted as a hollow arrow end) or destination (filled arrow end)
Filters defined as expressions loosely based on OCL and which are associated to links In these expressions a question mark () symbol represents user input
All these symbols can be observed in Fig 7 This figure depicts a possible OO-H navigation model corresponding to our checkout running example Fig 7 also illustrates how the process view provides the necessary information to generate a default navigation view enabling in this way the automatic generation of a navigation model out of a process model In order to get this navigation model we have applied a predefined set of mapping rules which can be summarized as follows
In Table 1 we observe how non-transactional activities are transformed into navigational links which will need to be further refined with a navigation filter that completes the activity specification Transactional activities andor transactional subactivity states on the contrary require the support of an underlying domain operation that hides and preserves such transactional character Operations are accessed at NAD level by means of service links On the other hand non-transactional subactivity states can be regarded as navigational subsystems and therefore materialized in a OO-H Navigation target associated with each of the defined subsystems Transitions trivially map to traversal links which are by default activated by the user and cause a change of user view
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Table 1 Mapping Rules between Process View and Navigation View in OO-H
Branches can be regarded as menus where only one option is available at a time This fact is modeled in OO-H by means of a collection construct and a set of traversal links each one with an exclusive filter associated Merge constructs on the other hand cause the generation of a collection that is the target for a set of automatic traversal links
Last the synchronization bars (split-join constructs) cause the generation of a default path that traverses the concurrent activities in arbitrary order (namely from top to bottom and from left to right)
CustomerView Customer
COL1
AddNewCustomer[precond contextemailAddress=]
DN3SetOptions
DN6PlaceOrder
COL3
CustomerView2 Customer
setPasswd()
[precond Contextpasswd-gtisEmpty()]
new()
PrecondContextpassword-gtnotEmpty()]
SignIn[precondContextemailAdress= and Contextpassword =
Fig 7 NAD Diagram for Customer Identification in the Checkout Process
As an illustrating example and looking back at the activity diagram of Fig 6 we observe that the first constructor that appears is the SignIn non-transactional call state This activity is materialized in Fig 7 in a navigational link with an associate filter (OCL
Activity Diagram Element NAD diagram element
Non-Transactional Activity Navigational link refined with precondition filter
Transactional Activity Service link associated with a Navigational class
Transition Navigation target
Subactivity Service link associated with a Navigational class
Branch Traversal link
Merge Collection from which a set of Traversal links with exclusive filters departs
Split-Join Collection at which a set of Traversal links with no filters arrives
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
formula) that implements a query over the underlying information repository After this query has been performed and depending on whether the user is new or a returning customer a collection construct (col1 see Fig 7) drives us either to a new() method or to a SetOptions navigation target respectively Assuming that the user states he is new he will follow the AddNewCustomer link which first of all will demand the user to enter an emailAddress that is gathered in an OO-H predefined context object While the customer navigational class and the associated service link have been generated automatically the filter is a refinement added by the designer on the default model to correctly capture the Amazon interface
This email value will be then used to provide a value to one of the parameters defined for the new() service that can be accessed through the CustomerView When the underlying operation returns the control and assuming that everything is OK a system automatic traversal link (dotted arrow) drives the user to the SetOptions Navigation Target
This diagram also shows the association between activities and classes andor domain operations As an example the association of the AddNewCustomer activity of Fig 6 with the new() operation in the Customer class has caused the inclusion of a CustomerView and a service link associated (see Fig 7)
If we now enter the SetOptions navigation target generated after the homonim subactivity state we may observe how all options may be performed in parallel Navigationally speaking and in order to assure that the completion of all the parallel activities is possible OO-H infers a navigation path that sequentially traverses the constructs associated with each one of these activities (see Fig 8)
OrderItem OrderItem
confirmItem()
Order3 Order
setPaymentOptions()
Order1 Order
setWrappingOptions()
Order2 Order
setShippingAddress()
COL3LR9
COL4 COL5 COL6
PlaceOrder Order
Fig 8 NAD Diagram Corresponding to the SetOptions Subactivity State
Once the whole navigation model has been refined a default presentation model can be automatically generated in the OO-H development environment In order to complete the application specification OO-H provides a presentation model that is partly-based on the design models presented so far and that falls out of the scope of this paper
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
5 DESIGN OF WEB BUSINESS PROCESS WITH UWE
The UWE methodology [Koch amp Kraus 2002] is an object-oriented and iterative approach based on the standard UML The main focus of UWE is the systematic design followed by a semi-automatic generation of Web applications To support the systematic design the CASE-tool ArgoUWE (an extension of ArgoUML2) is currently being implemented The semi-automatic generation of Web applications is supported by the UWEXML ndash a model-driven Code Generator for deployment to an XML publishing framework Both are part of the OpenUWE development environment The common language for data interchange within this architecture is defined by the UWE metamodel defined as a conservative extension of the UML metamodel and therefore a MOF (Meta Objects Facility) compatible metamodel [Koch amp Kraus 2003]
The UWE metamodel elements are also the basis for the UWE notation which is defined as a ldquolightweightrdquo UML profile ie a UML extension based on the extension mechanisms defined by UML The UWE profile includes a set of Web specific modeling elements for navigation presentation process and personalization In this section we will focus on the notation used by UWE for business processes and the development steps to build such category of applications
The UWE design approach for Web business process in the same way as OO-H does is based on the models built during the analysis phase ie the conceptual model and the process model both presented in Section 4 It uses standards not only to build the analysis models but UWE also sticks to the UML in this design phase In this phase UWE selects the appropriate diagram types and proposes to enrich the UWE Profile with a couple of modeling elements improving in this way the expressiveness of the UML constructs for the Web domain In the treatment of business processes UWE differs from OO-H by not mapping the process model to the navigation model but additionally introducing specific process classes that are part of a separate process model with a clear interface to the navigation model
Design of Web business applications following the UWE methodology requires the following activities First the refinement of the conceptual model adding attributes and methods to the already identified classes We will neither detail this refinement process nor depict the resulting diagram in this work as these are well known activities done in object-oriented development Second the integration of the processes in the navigation model to indicate browsing possibilities Third the refinement of the process model building a process structure and a process flow view Last but not least the presentation model is built based on the navigation and process models showing how the navigation paradigm and the business processes are combined
51 INTEGRATION OF PROCESSES IN THE NAVIGATION MODEL Navigation modeling activities in UWE comprise the construction of the navigation model in two steps First the objective is to specify which objects can be visited by navigation through the application Incorporating to this diagram additional constructs it
2 wwwtigrisorg
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
is shown how the user can reach the navigation elements The navigation model is represented by a stereotyped class diagram It includes the classes of those objects which can be visited by navigation through the Web application such as classes Product ShoppingCart Order Customer Book etc UWE provides a set of guidelines and semi-automatic mechanisms for modeling the navigation of an application which are detailed in previous works [Koch and Kraus 2002] This automation as well as model checking is supported by the CASE tool ArgoUWE [Zhang 2002]
UWE defines a set of modeling elements used in the construction of the navigation model For the first step the laquonavigation classraquo and the laquonavigation linkraquo have been used until now to model nodes and links For modeling process-aware Web applications we introduce two additional stereotypes laquoprocess classraquo and laquoprocess linkraquo which are defined with the following semantic
bull process class models a class whose instances are used by the user during execution of a process It is possible to define a mapping function between laquoprocess classraquo classes and use cases (those use cases not stereotyped as laquonavigationraquo) in a similar way to the mapping function defined between navigation classes and conceptual classes
bull process link models the association between a laquonavigation classraquo and a laquoprocess classraquo This process link needs to have associated information about the process state ie they may be constraint by an OCL expression over the process state This allows resuming activities within the process under certain conditions
+recommendedBooks
Bookltltnavigation classgtgt
SignInltltprocess classgtgt
Customerltltnavigation classgtgt
ltltprocess linkgtgt
ShoppingCartItemltltnavigation classgtgt
AddToCartltltprocess classgtgt
OrderItem
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
11
ltltprocess linkgtgt
1+customer
1
ShoppingCartltltnavigation classgtgt
0+shoppingCartItems
0
01+shoppingCart 01
Order
ltltnavigation classgtgt
1+orderItems 1
0
+orders
0
Checkoutltltprocess classgtgt ltltprocess linkgtgt
Productltltnavigation classgtgt
+product ltltprocess linkgtgt
1+products 1ltltprocess linkgtgt
Fig 9 UWE Navigation Model (First Step) of the Checkout Process in wwwamazoncom
Process links in the navigation model indicate starting points of process within the navigation structure (see Fig 9) This process link can be bi-directional such the case of
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
the process links related to AddToCart and SignIn or the model should include another laquoprocess linkraquo that establishing where the navigation will continue after the process ends such as by the CheckoutProcess The process itself is defined in a separate model (see next section)
Fig 9 shows the navigation model after its first construction step Note that associations which are not explicitly stereotyped are stereotyped associations of type laquonavigation linkraquo (we omit them to avoid overloading) As example of a Amazon product line we only show the laquonavigation classraquo Book to keep the diagram simple as no modeling differences would be shown by including other product lines such as classes DVD or CD Although the notation for a bidirectional link with a line without arrows is not intuitive we prefer to stick to the UML notation
The second step in the construction of the navigation model consists of the enhancement of the model by a set of access structures needed for the navigation In a first step this enhancement is partially automated it consist in introducing indexes guided-tours and queries For each of these constructs UWE defines a stereotyped class laquoindexraquo laquoqueryraquo and laquoguided tourraquo In Fig 10 we use icons for indexes (eg OrderList) and queries (eg SearchProduct) which are defined by UWE within the UML extension mechanisms [Koch amp Kraus 2001]
ltltprocess linkgtgt
Bookltltnavigation classgtgt
Customer
ltltnavigation classgtgt
Homepageltltnavigation classgtgt
BookRecommendation
11
AccountInfo
+PersonalInfo
SignInltltprocess classgtgt
ltltprocess linkgtgt
OrderList
+OrderView
CustomerOrders
Orderltltnavigation classgtgt
00
00
MainMenu+Recommendations +YourAccount
SignIn
ltltprocess linkgtgt
SearchProducts
+Search
ShoppingCartItemsOrdeItems
SelectedResults
ShoppingCartItemltltnavigation classgtgt
00
OrderItemltltnavigation classgtgt
00
AddToCartltltprocess classgtgt
ShoppingCartltltnavigation classgtgt
01
+ViewCart
Checkoutltltprocess classgtgt
Productltltnavigation classgtgt
11
ltltprocess linkgtgt
ltltprocess linkgtgt
Fig 10 UWE Navigation Model (with Access Elements) of the Checkout Process
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Further the model is enriched automatically with menus for which construct UWE includes a stereotyped class laquomenuraquo For all these constructs UWE defines the semantic based on the extension of the UML metamodel with UWE specific modeling elements and using the Object Constraint Language (OCL) to define invariants on these constructs Fig 10 shows the result of the complete navigation modeling process In this second step as we use already defined UWE modeling elements there is no need to improve this model to model Web business processes beyond the laquoprocess classraquo and laquoprocess linkraquo defined above
52 REFINEMENT OF THE PROCESS MODEL At design level UWE proposes to build a process model which has a structural view and a behavioral view also called the process flow model Another view is the integration view with the navigation model ndash already presented in the previous section ndash which is depicted in the navigation model defining process entry and exit points between process execution and navigation These concepts are similar to the ldquostart activityrdquo and ldquoend activityrdquo concepts of Brambilla et al [2002] Unlike them however we model the process itself independently from the navigation emphasizing in this way the separation of aspects in the design of Web applications
In Fig 11 the structural process model for the Checkout process of the Amazon example is depicted The structural process model is ndash like the navigation model ndash derived from the conceptual model The difference to the navigation model is that the objective of this model is to capture the process related information comprising structure and behavior As it is shown in Fig 11 part of the process state is implicit by the cardinality 01 to other process classes meaning that at runtime these links exist or do not exist
PaymentOptionsltltprocess classgtgt
- creditCardNumber- creditCardExpire- creditCardOwner- creditCardType- payment = PaymentType
+ checkCreditCard() Boolean
Orderltltprocess classgtgt
+ sendInvoice()
Checkoutltltprocess classgtgt
- state CheckoutActivity
+ changeState()0101
01
Customerltltprocess classgtgt
+ setPaymentOptions()
01
ShoppingCartltltprocess classgtgt
+ placeOrder() Order
01
1 1
CheckoutActivityltltenumerationgtgt
-welcome-items-shipping
PaymentTypeltltenumerationgtgt
-moneyOrder-creditCard
01
Fig 11 Process Structural View of the Checkout Process in wwwamazoncom
Conversely we allow new modeling elements in the process model which are not derived from any conceptual model element The notation of this model is a class diagram using the stereotype laquoprocess classraquo A special process class that is not derived from the conceptual model is PaymentOptions containing information about the payment options The attributes of these classes express data needed by the process including user input such as the attributes of the process class PaymentOptions and process state information such as the attribute state of the class Checkout
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Every process is assigned to exactly one process class and for all these process classes a process flow model ie a UML activity diagram is defined The process state can be made explicit by introducing state attributes in the process class as shown in Fig 11 or it is derived from process classes in the transitive closure concerning associations of the particular process class Such a state allows for a re-initiation of the process after an interruption without going through all the steps the user has gone the first time Operations are used to validate data and to change the system state in synchronization with the conceptual model Data validation queries can be specified by OCL post conditions and are thus automatically transformable to code For example for the class PaymentOptions validation operations (checkCreditCard) are defined for the validation of the entered data and for the validation of the credit card information
AddNewCustomer
SetOptions
setPaymentOptions (Customer)
placeOrder (ShoppingCart)
[ customer-gtnotEmpty() ] [ customer-gtisEmpty() ]
Customer
ltltprocess classgtgt
new Customer
ltltprocess classgtgt
PaymentOptions
ltltprocess classgtgt
Orderltltprocess classgtgt
sendInvoice(Order)
ShoppingCart
ltltprocess classgtgt
SignIn
ltlttransactionalgtgt
ltlttransactionalgtgt
ltlttransactionalgtgt
SetPassword
[ newCustomer ]
[ returningCustomer ]
ltlttransactionalgtgt
Fig 12 UWE Process Flow Model of the Checkout Process in wwwamazoncom
The process flow model depicted in Fig 12 is a refinement of the process model at analysis level (see Fig 3) consisting of UML activity diagrams Every activity is either a UML subactivity state or a UML call state UML defines a subactivity state as the representation of the execution of a non-atomic sequence of steps that has some duration (set of actions and possibly waiting for events) A UML call state is an action state (atomic action) that calls a single operation Note that we strictly follow the notation and semantic that the UML defines for modeling elements used in activity diagrams eg
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
subactivity state icon The process flow for a subactivity state is captured in another process flow model ie activity diagram Call states can only be specified for operations we define them for operations of process classes in the structural process model Our example includes the call states setPaymentOptions placeOrder and sendInvoice This includes the validation of process data and the call of operations that change the process model as well as the underlying conceptual model By supplying guard expressions on branches following such a call state we can model the process flow depending on the result of operations of the process information model To note is that call state names are the name of the operations and are not written beginning with a capital letter
Process class object flow states are used to express user input and output In our example therefore we model the call state setPaymentOptions explicitly (not as part of the subactivity state SetOptions) The PaymentOptions object flow state represents input from the user and the corresponding submit button in the presentation model will trigger the transition to the setPaymentOptions call state (see Fig 12) Similarly to OO-H call states may be stereotyped as laquotransactionalraquo to express the transactional character of those action states
53 SUPPORT OF PROCESSES IN THE PRESENTATION MODEL
The presentation model of UWE allows for the specification of the logical presentation of a Web application Based on this logical model a physical presentation can be built which contains further refinements of the elements for the physical layout eg font and colors This physical representation which is not within the scope of this work cannot be captured by any UML model
Within the presentation model we distinguish two different views
bull structural view showing the structure of the presentation space bull user interface (UI) view presenting details about the user interface elements in the
pages
The goal of the structural view of the presentation is to model how the presentation space is divided which presentation elements are displayed in the same space (but not at the same time) and how presentation elements can be grouped Fig 13 shows the presentation structure view for our example the Checkout process
The central concept around which the structuring of the presentation space takes place is the concept of location Therefore we define in the UWE metamodel an abstract class with stereotype laquolocationraquo which is the generalization of stereotyped classes we can observe at Fig 13 ie laquolocation groupraquo laquolocation alternativeraquo and laquopresentation classraquo The semantic of these stereotyped classes is defined as follows
bull laquolocation groupraquo stereotyped classes are used to model the presentation sub-structure eg as a set of pages They aggregate a list of sub-locations
bull laquolocation alternativeraquo stereotyped classes are used to model presentation alternatives among laquolocationraquo classes optionally a default alternative can be specified
bull Stereotype laquopresentation classraquo represents logical page fragments and is composed of the logical user interface elements presented to the user of the application Every laquopresentation classraquo element is related to exactly one laquonavigation classraquo element of
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
the navigation model or one laquoprocess classraquo element of the process model defining thereby the presentation for this particular element
Checkout
ltltlocation groupgtgt
Header
ltltlocation alternativegtgt
StateImageltltpresentation classgtgt
ConfirmItems
ltltpresentation classgtgt
Welcome
ltltpresentation classgtgt
SetAddresses
ltltpresentation classgtgtSetWrapOptions
ltltpresentation classgtgt
SetShippingOptions
ltltpresentation classgtgt
SetPaymentOptions
ltltpresentation classgtgtPlaceOrder
ltltpresentation classgtgt
Activityltltlocation alternativegtgt
derivedFrom= Checkoutstate
Fig 13 Presentation Structure View of the Checkout Process
As shown in Fig 13 the location Checkout is divided in two alternative sub-locations exactly one Header and one alternative location Activity whereas the activities of the checkout process are presented for the interaction with the user The Header includes an image StateImage which visualizes the current step (activity) of the checkout process The dependency to the current activity is modeled by the tagged derivedFrom with value given by the attribute state of class CheckoutProcess
Fig 14 depicts the detailed user interface view of the presentation class for the PaymentOptions process class We use an alternative UML notation for the composition relationship showing the composed user interface (UI) elements within the visual container of a presentation class Although this notation is not supported by most of the UML CASE Tools we use it in this work as it allows for a more intuitive sketch as the traditional composition relationship when depicting the user interface view
The presentation class SetPaymentOptions is presented as part of the location group Checkout together with the presentation class SetImage that shows in an image the current state of the checkout process Every type of user interface element has a stereotype associated with it eg laquotextraquo laquoimageraquo laquoradio buttonraquo etc They are connected to the features (ie attributes or operations) of the underlying navigation or process classes in the case of dynamic user interface element Additionally these types of user interface elements can be used for static user interface elements as in the example static text (SelectPayment) or static images (CardLogos)
The type of user interface element used to present the corresponding elements of the underlying models depends from their type and the intended use An laquoinputraquo element for example can be used for displaying information as well as for information input in the case of attributes of a process class eg the CardNumber element in the example The
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
laquoradio buttonraquo element can be used to express the choice between different alternatives such as the payment methods in our example The attached user interface elements reflect the active UI elements for each case
SetPaymentOptionsltltpresentation classgtgt
CardLogos
ltltimagegtgtSelectPayment
ltlttextgtgt
PaymentMethod
ltltradio buttongtgt
CreditCards
ltltpulldown menugtgt
AmazonCreditAccount
ltltbuttongtgt
PayByMoneyOrder
ltltbuttongtgt
CardNummer
ltltinputgtgt
ExpirationMonth
ltltpulldown menugtgt
ExpirationYear
ltltpulldown menugtgt
GiftCertificate
ltlttextgtgtGiftCertificateCode
ltltinputgtgt
Password
ltltformgtgtContinue
ltltbuttongtgt
Checkout
ltltlocation groupgtgt
StateImageltltpresentation classgtgt
CheckoutProcessStateImage
ltltimagegtgt
Fig 14 UI Elements View for the Presentation Class SetPaymentOptions
A special case is the laquobuttonraquo element Continue (see Fig 14) which triggers the setPaymentOptions call state in the corresponding process model
6 CONCLUSIONS
The inclusion of process definition mechanisms in the context of Web methodologies is not only a must imposed by enterprise demands but also convenient from the point of view of increased support to the application evolution This evolution support is necessary due to the frequent appearance of new or changed business requirements In this sense we believe that the greater flexibility that comes with the explicit definition of such processes will induce a faster implementation of these changes
Being the notation associated with Web Engineering methods and methodologies so different from approach to approach the first temptation is to strive (as we have been doing up to now) to find individual solutions to this new challenge This effort enriching as it is suffers from the danger of providing enterprises and researchers with different vocabularies constructs and models to refer to eventually very similar concepts (although usually with different nuances) Such little differences are however enough as to make very difficult for us to reach general agreements as different research events had shown in the past
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
That is the main reason why in this article we have tried to work the other way round OO-H and UWE are very different proposals On one hand the OO-H method follows a bottom-up approach uses standards only in some phases of the modeling process and tries to keep the set of diagrams to a minimum in order to ease the work of model compilers for the automatic generation of Web interfaces
On the contrary UWE is exclusively based on standards It is a top-down approach that defines their modeling elements based on a metamodel defined in UML and defined as an extension of the UML metamodel UWE uses whenever possible the constructs provided by the UML and in some cases extends the notation to support the Web development specific characteristics The extensions are then strictly performed according to the extension mechanisms provided by the UML In addition UWE focus on a systematic development process but this subject was not within the scope of this work
In spite of these differences it was possible to reach agreements on the main concepts to be included in both OO-H and UWE and to define a common approach for the modeling activities during the analysis phase of Web business intensive applications Among these agreements it is interesting to note how both approaches opted unlike previously existing proposals [Bambrilla et al 2002] for defining a separate model to address process concerns We believe that providing separate models not only eases the construction and maintenance of such models but also reflects the fact that the same process may be the basis on which different interfaces may be defined all of them giving support to this process
Another important contribution of this work is the identification of at least two possibilities for the treatment of process concerns in the design phase of Web applications development On one hand OO-H has opted for the definition of default mapping rules that make possible the definition of default navigation maps based on the defined activity flows OO-H therefore considers that the purpose of certain navigation links may be regarded as that of guiding the user through the different process steps OO-H comes together with a prototyping environment that is based on its navigation diagram Embedding process concerns in this navigation diagram makes trivial the prototyping of such process in order for the user to validate it Furthermore in this way we have kept the set of design constructs needed to define a Web interface to a minimum
UWE instead has opted for design flows of control for process modeling in addition to the navigation model which is only enriched to reflect a set of integration points that is points in which the user may leave the navigation view to enter a process view At presentation level the same set of presentation modeling elements is used to support both the navigation and the process This loose integration supports a clear separation of concerns and enables reuse of processes such as customer login and checkout in different context or applications Furthermore it eases the maintenance and Web application evolution
7 FUTURE WORK
We plan to include the extension to our methods OO-H and UWE to support business process modeling in our CASE tools VisualWADE and ArgoUWE respectively
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
VisualWADE needs to include support both for UML activity diagrams and for the new laquotransactionalraquo stereotype Also we are working on the refinement of the mapping process between activity diagrams and NAD In this sense the definition of OCL guard conditions associated with transitions may provide automatic generation of some of the filters included at NAD level Also detailed object flows complementing the activity diagram may simplify the definition of the service interfaces affected
ArgoUWE will be extended to support process modeling as defined in this work The new modeling elements have been already included in the UWE Metamodel The consistency between the process model and the already existing navigation and presentation models will be checked on the basis of OCL constraints that improve the already existing set of about 20 constraints used for the UWE model checking
REFERENCES
[Atzeni amp Parente 2001]
Paolo Atzeni Alessio Parente (2001) Specification of Web Applications with ADM-2 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Baresi et al 2001] Luciano Baresi Franca Garzotto Paolo Paolini(2001) Extending UML for Modeling Web Applications 34th Hawaii International Conference on Systems Sciences
[Brambilla et al 2002] Marco Brambilla Stefano Ceri Sara Comai Piero Fraternali (2002) Specification and Design of Workflow-Driven Hypertext Journal of Web Engineering Vol 1 No 1
[Cachero 2003] Cristina Cachero (2003) OO-H Una extensioacuten a los meacutetodos OO para el modelado y generacioacuten automaacutetica de interfaces hipermediales Available online at httpwwwdlsiuaes~ccacheropTesishtm
[Cachero amp Gomez 2002]
Cristina Cachero Jaime Goacutemez (2002) Advanced Conceptual Modeling of Web Applications Embedding Operation Interfaces in Navigation Design 21th International Conference on Conceptual Modeling El Escorial Madrid Nov 2002
[Ceri et al 2002] Stefano Ceri Piero Fraternali Mariestella Matera (2002) Conceptual Modeling of Data-intensive Web Applications IEEE Internet Computing 6 (4) 20-30
De Troyer amp Casteleyn 2001]
Olga de Troyer Sven Casteleyn (2001) The Conference Review System with WSDM 1st International Workshop on Object Oriented Software Technology Valencia Spain
[Escalona amp Koch 2003]
Mariacutea Joseacute Escalona Nora Koch (2003) Ingenieriacutea de Requisitos en Aplicaciones para la Web Un Estudio Comparativo IDEASrsquo03
[Gomez et al 2001] Jaime Goacutemez Cristina Cachero Oscar Pastor (2001) On Conceptual Modeling of Device-Independent Web Applications Towards a Web Engineering Approach IEEE Multimedia 8(2) 20-32 Special Issue on Web Engineering
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
[Jacobson et al 1992] Ivar Jacobson Magnus Christersen Patrik Jonsson Gunner Overgaars (1992) Object-oriented Software Engineering A Use Case Driven Approach Addison Wesley
[Kahn et al 1957] Robert Kahn Charles Cannell (1957) The dynamics of interviewing theory technique and cases New York Wiley
[Koch amp Kraus 2002] Nora Koch Andreas Kraus (2003) The expressive power of UML-based engineering Proceedings of the IWWOSTrsquo02 CYTED 105-119
[Koch amp Kraus 2003] Nora Koch Andreas Kraus (2003) Towards a Common Metamodel for the Development of Web Applications International Conference of Web Engineering LNCS Springer Verlag to appear
[Korthaus 1998] Axel Korthaus (1998) Using UML for Business Object Based Systems Modeling UML Workshop 1997 Mannheim Germany
[Markopoulos 2000] Panos Markopoulos (2000) Supporting Interaction Design with UML Task Modelling TUPIS Workshop at the UML2000
[Nunes amp Cunha 2000] Nuno Nunes Joseacute Cunha (2000) Towards a UML Profile for Interaction Design The Wisdom approach Proceedings of the Unified Modeling Language Conference UMLacute2000 Evans A and Kent S (Eds) LNCS 1939 Springer Publishing Company 100-116
[Retschitzegger amp Schwinger 2000]
Werner Retschitzegger Wieland Schwinger (2000) Towards Modeling of Data Web Applications - A Requirementrsquos Perspective American Conference on Information Systems AMCIS 2000 Vol 1 149ndash155
[Schwabe et al 2001] Daniel Schwabe Esmeraldo L Gustavo Rossi Fernando Lyardet (2001) Engineering Web Applications for Reuse IEEE Multimedia Special Issue on Web Engineering 01-03 20ndash31
[UML 2003] UML 15 Standard OMG (2003) wwwomgorg
[Zhang 2002] Gefei Zhang (2002) ArgoUWE a CASE Tool for Web Applications wwwpstinformatikuni-muenchendeprojekteargouwe
Recommended