J.E.D.I
4. For controllers that require a longer time to process, keep user informed of what is going on. Use XX completed messages or line indicators.
5. If possible, it would be wise to always inform the user of the next step. Wizard-type dialog design is always a good approach.
6. Provide meaningful error messages and help screens. AVOID PROFANITY
Developing the Screen and Dialog Design
STEP 1: Prototyping the User-interface.
A prototype is a model that looks, and to some extent, behaves like the finished product but lacking in certain features. It is like an architects scale model of a new
building. There are several types of prototypes.
1. Horizontal prototypes provide a model of the user interface. It deals only
with the presentation or view layer of the software architecture. Basically, this type of prototype shows the screen sequencing when the user interacts with the
software. No functionality is emulated.
2. Vertical prototypes takes one functional subsystem of the whole system and
develops it through each layer: user-interface, some logical functionality and database.
3. Throwaway Prototypes are prototypes that are discarded later after they
have served their purpose. This type of prototype is done during the requirements engineering phase. As much as possible, we avoid creating such
prototypes.
The use of Visual Programming Environment can support the development prototypes. NetBeans and Java Studio Enterprise 8 provides a means to visually create
our prototypes.
To demonstrate step one, assume we are building a screen prototype for maintaining an athlete record. The main screen, which is named Athlete Figure 4.37, allows us to
manage a single athlete record. When a user clicks the Find Button, the Find an Athlete
Figure 4.38 screen appears. This screen is used to specify the search criteria that determines which athlete records that are retrieved from the database. When the
criteria has been entered and the OK Button is clicked, the Athlete List Figure 4.38 screen will be displayed containing the list of athletes that satisfies the search criteria.
The user can select the record by highlighting the name. When the OK Button is clicked, it will return to the Athlete screen where the attributes of the choosen athlete are
displayed in the appropriate screen elements.
Software Engineering 174
J.E.D.I
Software Engineering 175
Figure 4.37 Screen Prototype of Athlete Record
Athlete
Membership No:
Address Lot 24 Block 18, St.
Andrewsfield Quezon City Postal Code
2619
Date of Birth 9241998 Gender
3456
Save Delete
Cancel Find...
Last Name First Name
De la Cruz Johnny
Middle Initial A.
Male Female
Address Lot 24 Block 18, St.
Andrewsfield Quezon City 2619
Last Name First Name
De la Cruz, Sr. Johnny
Middle Initial A. Guardian:
Postal Code
Telephone 555-9895
Status Active
J.E.D.I
Software Engineering 176
Figure 4.38 Screen Prototypes of FindAthleteRecordUI and AthleteListUI
Athlete List
OK
Athlete ID Last Name
First Name MI
3303 Armstrong
Mark L.
3307 Brown
Lione G.
3312 Ferran
Julius R.
3318 Jones
Simon R.
3323 Napoli
Ray F.
3326 Robinson
James S.
3336 Schmidt
John C.
3343 Smith
Allan A.
3344 Smith
Jacob F.
3347 Smith
Kenny S.
3348 Smith
Leo A.
Cancel
Find An Athlete
Membership No:
Date of Birth 911998 Gender
Cancel OK
Last Name First Name
Middle Initial
Male Female
To 9301998 Status Active
J.E.D.I
In the following steps, screens will be treated as single objects. In reality, they may well be an instance of a subclass such as Dialog. As an example, take a look at Figure 4.39.
In Java, you can use the Java AWTSWING component. They are imported in the class that use them using the following Java statements:
import java.awt.; import java.awt.swing.;
STEP 2: For each screen, design the screen class. This step would require us to model the screen as a class. As an example, consider
Figure 4.40 which
provides the class definition for the Athlete screen. The name of the class is AthleteRecordUI. It has a screen stereotype. In this example, we assume
that we will be using the JAVA Abstract Windowing Toolkit AWT for support components. You also need to model the screens Find an Athlete and Athlete List
as classes; they are named FindAthleteRecordUI and AthleteListUI respectively. Package all the screens together to form the subsystem. This subsystem should
implement the IAthleteRecordUI interface for the boundary class. See Figure 4.41.
Software Engineering 177
Figure 4.39 Dialog Class Diagram
J.E.D.I
STEP 3: For each screen class, model the behavior of the screen with other classes. The behavior of the screen class relative to the other classes is known as the dialog
design. The collaboration diagrams and sequence diagrams are used in this step. As in our working example, there are three main functionality for managing an athlete record
that must be supported, namely, add, edit and delete an athlete record. Consider the collaboration diagrams as modeled in Figure 4.42. The first collaboration diagram
models how the system manages an athlete record; and, it consists of the AthleteRecordUI
, MaintainAthleteRecord and DBAthlete classes. It is elaborated by
the second collaboration diagram. Additional classes are identified and defined to
Software Engineering 178
Figure 4.40 Class Definition of AthleteRecordUI
Figure 4.41: IAtheteRecordUI Interface and Subsystem Definition
J.E.D.I
support retrieval of an athlete record from the database as needed by the edit and delete athlete record functionality.
These classes are FindAthleteRecordUI,
FindAthleteRecord and AthleteListUI.
Software Engineering 179
Figure 4.42 Modified Collaboration Diagram with AthleteRecordUI
J.E.D.I
Once the collaborating objects are identified, we need to model their behavior when the functionalities add, edit and delete athlete record are performed. We use the Sequence
Diagram to model this behavior. Figure 4.43 shows the modified sequence diagram of adding an athlete record This sequence diagram is an elaboration of DBAthlete JDBC
Create of adding an athlete record as was discussed in the Data Design Section.
Software Engineering 180
Figure 4.43 Modified Sequence Diagram of Adding an Athlete Record
J.E.D.I
Both the sequence diagrams for editing and deleting an athlete record would require a retrieval of a record from the database. Prior to editing and deleting, the sequence
diagram shown in Figure 4.44 must be performed. This sequence diagram is an elaboration of DBAthlete JDBC Read of an athlete record as it was discussed under the
Data Design Section.
Software Engineering 181
Figure 4.44 Modified Sequence Diagram of Retrieving an Athlete Record
J.E.D.I
Software Engineering 182
Figure 4.46 Modified Sequence Diagram of Deleting an Athlete Record Figure 4.45 Modified Sequence Diagram of Editing an Athlete Record
J.E.D.I
The modified sequence diagram for editing and deleting an athlete record are shown in Figure 4.45 and Figure 4.46 respectively. They are also an elaboration of the DBAthlete
JDBC Update and DBAthlete JDBC Delete respectively.
STEP 4. For each screen class, model its internal behavior. The State Chart Diagram is used to model the internal behavior of the screen. It
basically models the behavior of the screen when a user does something on the screen elements such as clicking the OK Button.
Describing the State Chart Diagram The State Chart Diagram shows the possible states that an object can have. It also
identifies the events that causes the state change. It shows how the objects state changes as a result of events that are handled by the object. Figure 4.47 shows the basic
notation of the diagram.
The initial state, as represented by a solid filled circle, signifies the entry point of the transition. An object cannot remain in its initial state but needs to move to a named
state. The state is represented as a rounded rectangular object with the state name inside the object. A transition is represented by an arrow line. A transition should have
a transition string that shows the event that causes the transition, any guard conditions that needs to be evaluated during the triggering of the event, and the action that needs
to be performed when the event is triggered. The event should be an operation defined in the class. The final state, as represented by the bulls eye, signifies the end of the
diagram.
Similar with other diagrams in UML, there is an extended or enhanced notation that can be used when defining the state of a class. Figure 4.48 shows the these notations.
Software Engineering 183
Figure 4.47 State Chart Diagram Basic Notation
Initial State Final State
State Transition
State1
State2 [guard conditions]
eventparameters actionparameters:returnType
J.E.D.I
Concurrent states means that the behavior of the object can best be explained by regarding the product as two distinct set of substates, each state of which can be entered
and exited independently of substates in the other set. Nested states allow one to model a complex state through defining different level of detail. States can have internal
actions and activities. Internal actions of the state defines what operation should be perform upon entering the state, what operation should be perform upon exiting the
state, and what operation should be perform while the object is in that state.
Figure 4.49 shows the state chart diagram of the AthleteRecordUI class. When the screen is first displayed, it will show an initialized screen where most of the text boxes
are empty. Some fields may have default values such as Gender with a default value of Male and Status with the default value as NEW. This state is the With Default Value
state. When a user enters a value on any text field this triggers an enterTextField event, the screens state will move to the With Entered Value state where the entered
value is reflected on the screen element. When a user clicks the Cancel Button which triggers the clickCancelButton event, the screen state will move to the Show Exit
Confirmation
state. In this state, a message dialog box will be displayed asking the user if he or she really wants to exit. If the user answers YES, we exit the screen.
Otherwise, we go back to the previous state.
Figure 4.50 shows the FindAthleteRecordUI state chart diagram and Figure 4.51 shows the AthleteListUI state chart diagram.
Software Engineering 184
Figure 4.48 State Chart Diagram Enhanced Notation
J.E.D.I
Software Engineering 185
Figure 4.49 AthleteRecordUI State Chart Diagram
Figure 4.50 FindAthleteRecordUI State Chart Diagram
J.E.D.I
STEP 5: Document the screen classes. The documentation is similar to documenting DBClasses and Persistent Classes. Identify
all the attributes and operations of the screen. Figure 4.52 shows the class definition of all screens.
Software Engineering 186
Figure 4.51 AthleteListUI State Chart Diagram
Figure 4.52 Refined Screen Class Definition
J.E.D.I
It would also help to list the action in a table. This table is called the Event-Action Table. This is used if the state chart is complex. In the point of view of a programmer,
this table is easier to use than a state chart labelled with actions. It should help in validating the state chart and to test the code once it is implemented. The following are
the columns of the Event-Action Table:
● The current state of the object being modeled. For easy reference, we number the states.
● The event that can take place. ● The actions associated with the combination of state and event.
● The next state of the object after the event has taken place. If more than one state variable is used, another column is used.
Figure 4.53 shows the state chart diagram of the AthleteRecordUI screen with the states numbered.
Table 23 shows the Event-Action of this screen.
Software Engineering 187
Figure 4.53: AthleteRecordUI State Chart Diagram
J.E.D.I
Current State
Event Action
Next State
- Access
to the
AthleteRecordUI
Screen Display an empty Athlete Screen
except for identified screen elements with default values
1 1
enterTextField Display the typed value inside the
text field 2
2 clickStatusComboBox
Shows a list of athlete status 3
3 selectFromList
Display the selected athlete status in the display field
2 2
enterTextField Display the typed value inside the
text field 2
2 clickCancelButton
Show Exit Confirmation Dialog Box
5
5 AnswerYES
Exits the Athlete screen without saving any data displayed on the
screen -
5 AnswerNO
Close the Exit Confrimation Dialog Box
2 ...
... ...
...
Table 23: Event-Action Table of AthleteRecordUI Screen
Software Engineering 188
J.E.D.I
STEP 6: Modify the software architecture. The boundary subsystems are replaced by the classes for the screens or user interfaces.
If additional control classes are defined, add them to the architecture. Figure 4.54 shows the modified software architecture.
Software Engineering 189
Figure 4.54: Modified Software Architecture from User Interface Design Elaboration
J.E.D.I
4.6 Component-level Design
