University of Southern California
Center for Systems and Software Engineering
CS577a: Understanding the
SSAD, Use-Cases and
GUI Prototyping
David Klappholz, Nupul Kukreja
10/7/2009
© USC-CSSE 2005-2009
1
University of Southern California
Center for Systems and Software Engineering
Agenda
• Understanding the SSAD and what goes where
• Review of System Context and the Artifact & Information
Diagrams
• An overview about a more precise way of writing the English text
Use cases” – by looking at some of the use cases for the Internet
Bookstore system
• GUI Prototyping – what/how/why?
10/7/2009
© USC-CSSE 2005-2009
2
University of Southern California
Center for Systems and Software Engineering
System and Software Architecture
Description (SSAD)
• From the IICM-EPG:
The purpose of the SSAD is to document the
results of the object-oriented analysis and design
(OOA&D) of the system being developed.
The SSAD is used by the builder (programmer) as
reference to the system architecture. The system
being developed should be faithful to the
architecture specified in the SSAD.
Futhermore, the SSAD is used by the maintainer
and clients to help understand the structure of the
system once the proposed system is delivered
10/7/2009
© USC-CSSE 2005-2009
3
University of Southern California
Center for Systems and Software Engineering
SSAD – Layout
1. Introduction
2. System Analysis
 System Analysis Overview
 System Context
 Artifacts & Information
 Behavior
 Capability ‘X’
 Process ‘Y’
 Modes of Operation
 System Analysis Rationale
10/7/2009
© USC-CSSE 2005-2009
4
University of Southern California
Center for Systems and Software Engineering
SSAD – Layout (cont’d)
3. Technology Independent Model

Design Overview




System Structure
Design Classes
Process Realization
Design Rationale
4. Technology Specific System Design

(Same subsections as Section 3)
5. Architectural Styles, Patterns and
Frameworks
10/7/2009
© USC-CSSE 2005-2009
5
University of Southern California
Center for Systems and Software Engineering
SSAD – Sectional Overview
10/7/2009
© USC-CSSE 2005-2009
6
University of Southern California
Center for Systems and Software Engineering
System Analysis
• The ‘System Analysis Overview’ subsection
highlights the ‘high level’ analysis model of the
system to be developed
• It contains three important models
–System Context Diagram
–Artifacts and Information Diagram
–System Behavior (i.e., Use-Case Model and
Descriptions)
• We cover all of these in today’s lecture
10/7/2009
© USC-CSSE 2005-2009
7
University of Southern California
Center for Systems and Software Engineering
System Context
• In the previous lecture on ‘Architecture’ we mentioned that
every architectural element has an execution context – i.e.,
it’s dependencies on ‘other’ components, the execution
environment, files etc.,
• Similarly there exists a context for the System’s Execution
as a whole: the system to be developed also has various
dependencies – either on other systems, the physical
entities interacting with it etc.,
• It’s extremely important to capture this information to ensure
that the corresponding ‘interfaces’ for communication have
been designed for in the architecture
• Failure to capture this ‘context’ is a successful recipe for
failure!
10/7/2009
© USC-CSSE 2005-2009
8
University of Southern California
Center for Systems and Software Engineering
System Context Diagram (SCD) – A ‘black-box’ view of the system
10/7/2009
© USC-CSSE 2005-2009
9
University of Southern California
Center for Systems and Software Engineering
SCD - Notes
• On the previous slide we saw the SCD for the
Internet Bookstore System that we’ve spoken
about in the previous lectures
• All external ‘entities’ whether other systems or
humans are represented as ‘Actors’ as per the
UML notation
• The multiplicities and the ‘association names’
are made explicit for better understanding
• They help better scope the project before
committing for full up development right away.
10/7/2009
© USC-CSSE 2005-2009
10
University of Southern California
Center for Systems and Software Engineering
Artifact and Information Diagram
• Captures the ‘Persistent Data’ that the to-be-built system
needs to maintain
• Captured by the means of ‘Class Diagrams’ and can also
be referred to as a ‘Persistent Data Class Diagram’
• The ‘first-cut’ diagram need not have ‘attributes and/or
methods’ per se, but they need to be identified as one
gains more information
• These ‘classes’ are then mapped to RDBMS tables (can
also be to flat files and other storage mechanisms)
• Must be ‘normalized’ to at least 3NF (3rd Normal Form) for
storage – easier with class diagrams
• We see an example on the following slide – with some
nuances…
10/7/2009
© USC-CSSE 2005-2009
11
University of Southern California
Center for Systems and Software Engineering
Artifact and Information Diagram:
Internet Bookstore (subset)
1..*
10/7/2009
© USC-CSSE 2005-2009
12
University of Southern California
Center for Systems and Software Engineering
Artifacts & Information – Fine Print
• Key points to note:
– We showed only a very small subset of the persistent data that
they system needs to maintain
– The Master Book Catalog (MBC) ONLY has methods and NO
‘internal’ data of its own – it relies on data from the ‘Book’ class;
The requirement for this MBC class as a persistent class is
‘questionable’ and needs to be reviewed
– The Customer class has an explicit association to an Address
class rather than have ‘address’ as an attribute – this is an
example of ‘class normalization’ where complex attributes are
separated out into their own class
– The Account class is shown to have 2 subclasses – they could
have just been modeled as an ‘Account Type’ attribute that can
take either of the 2 subclass names as input values – needs to be
reviewed.
10/7/2009
© USC-CSSE 2005-2009
13
University of Southern California
Center for Systems and Software Engineering
Artifacts & Information – Extremely Fine Print
• There exists an “Object-Relational” mismatch that
must be addressed
• Examples:
– Many-to-many relations require a ‘mapping’ table in an
RDBMS, whereas this is inherently a part of the Object
Oriented representation
– The inheritance facility in the OO approach may not exist
in the underlying RDBMS and must be managed
accordingly (i.e., attribute based, table inheritance etc.,)
– Must deal with Data Normalization vs. Class
Normalization (subtly different)
– Foreign/Primary keys required for DB storage are NOT
explicitly captured in the OO Class Diagrams
10/7/2009
© USC-CSSE 2005-2009
14
University of Southern California
Center for Systems and Software Engineering
Addressing the Object-Relational Mismatch
• There MUST be appropriate provisions for providing
mappings between the ‘Object Schema’ and the
corresponding ‘DB Schema’
OR
• Have the underlying DB schema be of the form’ ONE
table per persistent class of the Object Schema’
– Advantage: Underlying ‘structure’ of the data is similar
to what the application expects
– Disadvantage: You could land up with lot of
redundant data and Data Modelers could give you a
tough time!
DO NOT underestimate the importance of Object
Persistence.
10/7/2009
© USC-CSSE 2005-2009
15
University of Southern California
Center for Systems and Software Engineering
Use-Cases
• Captured in the “Behavior” section of the
System Analysis in the SSAD
• The model is captured using RSM along with
a textual description for each of the ‘usecases’ (a.k.a Capabilities)
• The Use-case ‘Process’ is captured in a
tabular format – both the basic and alternate
courses of action are captured
(Note: All of the above is elaborated later in the
lecture)
10/7/2009
© USC-CSSE 2005-2009
16
University of Southern California
Center for Systems and Software Engineering
Modes of Operation
• Most systems developed as a part of 577 projects
do not have multiple ‘modes of operation’
• ‘Modes of Operations’ is there to explicitly state if
multiple such modes exist eg.:
– If a system explicitly operates in ‘user’ mode and
‘administrative’ mode it would offer access to
different (or extra) functionalities of the system
– A text editor like ‘Vi’ on Linux/Unix operates in
‘text’ mode and ‘command mode’
– The Windows OS offers a ‘safe mode’ that only
provides a subset of system functionality
10/7/2009
© USC-CSSE 2005-2009
17
University of Southern California
Center for Systems and Software Engineering
Technology Independent/Specific Model
It contains the following:
• System Structure
– Hardware Component (Class) Diagram
– Software Component (Class) Diagram
– Deployment Diagram
• We see examples of each on the following
slides
10/7/2009
© USC-CSSE 2005-2009
18
University of Southern California
Center for Systems and Software Engineering
Hardware Component Diagram
10/7/2009
© USC-CSSE 2005-2009
19
University of Southern California
Center for Systems and Software Engineering
Software Component Diagram
A package/component view of the various identified ‘components’ of the system
10/7/2009
© USC-CSSE 2005-2009
20
University of Southern California
Center for Systems and Software Engineering
Deployment Diagram
10/7/2009
© USC-CSSE 2005-2009
21
University of Southern California
Center for Systems and Software Engineering
Hardware Component Diagram (HCD)
Vs. Deployment Diagram
• The HCD shows what all hardware ‘component’ are
required for the application and how are they connected
to each other (i.e. Nodes in RSM)
• A deployment view contains ‘instances’ of the various
hardware components shown in the HCD (i.e., Node
Instances in RSM)
• Ex.:
– ‘Web Server Machine’ – is some machine that the server
executes on (if known in advance, you could also say for
example, ‘Sun Blade Machine’)
– ‘WinXP:Web Server Machine’ is an instance of the ‘Web
Server Machine’ on which various components are deployed
10/7/2009
© USC-CSSE 2005-2009
22
University of Southern California
Center for Systems and Software Engineering
Technology Independent/Specific Model - II
• System Structure also contains two very
important models:
– Design Classes
– Process Realization (Sequence Diagrams)
• In the subsequent lectures on OOA&D we would
be focusing on these aspects explicitly
• We would look at the progression from the
Domain Classes Analysis Classes Design
Classes that would then be documented in the
SSAD & the corresponding sequence diagrams
10/7/2009
© USC-CSSE 2005-2009
23
University of Southern California
Center for Systems and Software Engineering
Architectural Styles, Patterns and
Frameworks
• Here you state the choice of the architectural
style and the rationale for that choice
• You also highlight which external frameworks
would be used to develop the system. For
example, Struts, Hibernate, .NET etc.,
• As mentioned in the lecture on Architecture,
the difference between ‘Styles and Patterns’ is
very subtle and will not be distinguished in
577 and we will use the terms interchangably.
10/7/2009
© USC-CSSE 2005-2009
24
University of Southern California
Center for Systems and Software Engineering
Use Case Elaboration
Based on the Internet Bookstore System covered in the
previous OOA&D lectures
10/7/2009
© USC-CSSE 2005-2009
25
University of Southern California
Center for Systems and Software Engineering
Points to Note
• We assume that the ‘System Requirements’ have been
captured – they need not be finalized, but must have a
relative level of confidence on their accuracy (for the
Internet Bookstore example we assume that the ‘Desired
Functionalities’ outlined earlier have been
transformed/finalized into Requirements for the system –
shown on the following slide)
• The use-case elaborations presented are at a low level of
granularity – i.e., they talk about the ‘buttons’ or ‘links’ the
user must click etc.,
• Arriving at this level of granularity is “Iterative” – the initial
level of use-cases may be very coarse grained and not
have ANY reference to GUI elements whatsoever
10/7/2009
© USC-CSSE 2005-2009
26
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Requirements
•The bookstore shall accept orders over the internet
•The bookstore shall maintain a list of accounts for up to 1,000,000 customers
•The bookstore shall provide password protection for all accounts
•The bookstore shall provide the ability to search the master book catalog
•The bookstore shall provide a number of search methods on that catalog,
including search by author, search by title, search by ISBN number, and
search by keyword
•The bookstore shall provide a secure means of allowing customers to pay by
credit card
•The bookstore shall provide a secure means of allowing customers to pay via
purchase order
•The bookstore shall provide a special kind of account that is pre-authorized
to pay via purchase order
•The bookstore shall provide electronic links between the Web and
database and the shipping fulfilment center
•The bookstore shall provide electronic links between the Web and database
and the inventory management system
•The bookstore shall maintain reviews of books and shall allow anyone to
upload review comments
•The bookstore shall maintain ratings on books based on customer inputs
10/7/2009
© USC-CSSE 2005-2009
27
University of Southern California
Center for Systems and Software Engineering
Actors
• The “Actors” in a use case-style description of a software system are all the people
and all the outside hardware and software systems with which the application at
hand interacts – the domain model and business workflow too can be used for
identification/verification!
• Some of the Internet Bookstore actors are:
• The (potential) customer
• Shipping fulfillment center worker (see the requirements document)
• Possibly the web sites (i.e., web services) belonging to various shipping
companies like USPS, UPS, DHL, etc., i.e., if shipping fulfillment center
workers do such things as requesting pickups and checking on deliveries over the
Internet.
• Inventory management worker
• Various types of administrative employee(s)
10/7/2009
© USC-CSSE 2005-2009
28
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Use Cases
• In this part of the lecture we will use Internet Bookstore use
cases to introduce the style that we will be using for use case
descriptions for the rest of the course.
• The only actor with which we will be concerned here is the one
that we called “User” (or Customer) earlier in the lecture.
• The only use cases with which we will be concerned are those
whose titles are listed on the next slide. That is, we will not
consider any (additional) actors or use cases that relate to
either shipping fulfillment or inventory management
• Of course complete analysis & design of the Internet Bookstore
application requires that all actors and use cases be dealt with.
10/7/2009
© USC-CSSE 2005-2009
29
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore – A few Use Cases
•
•
•
•
•
•
•
•
Open Account
Log In
Search by Author
Browse List of Books
Edit Content of Shopping Cart
Check Out
Track Recent Orders
Cancel Order
10/7/2009
© USC-CSSE 2005-2009
30
University of Southern California
Center for Systems and Software Engineering
Use Case Descriptions
• The part of a use case description that relates what
happens when everything goes right is called the “basic
course” or the “sunny day course”
• The part of a use case description that relates what
happens when something goes wrong is called an
“alternate course” or a “rainy day course.”
• The next slide shows the basic course of the Internet
Bookstore’s Open Account use case in the style that we
will be using.
10/7/2009
© USC-CSSE 2005-2009
31
University of Southern California
Center for Systems and Software Engineering
Open Account Use Case:
Basic Course
1. The system displays the New Account Page.
2. The Customer types his or her name, an e-mail address,
and a password (twice), and then presses the Create
Account button.
3. The system ensures that the Customer has provided valid
data and then adds an Account to the Master Account
Table using that data.
4. The system then returns the Customer to the Home Page
10/7/2009
© USC-CSSE 2005-2009
32
University of Southern California
Center for Systems and Software Engineering
Open Account Use Case:
Basic Course (cont.)
• As indicated on a previous slide, a use case’s
“basic course” is a description of how the
relevant actor(s) and the application interact
when / if everything goes right e.g., in this case if
the customer, attempting to create a new
account:
–
–
–
–
–
types his/her name
types a syntactically valid email address
types a sufficiently long password
types exactly the same password for a second time
has typed a name and an email address that don’t
already correspond to an Internet Bookstore account
10/7/2009
© USC-CSSE 2005-2009
33
University of Southern California
Center for Systems and Software Engineering
Open Account Use Case:
Alternate Courses
• The next slide shows what seem to be five
different alternate courses for the Open
Account use case.
• A use case’s “alternative courses” are
descriptions of how the application (system)
reacts when the actor doesn’t do “the right
thing,”
10/7/2009
© USC-CSSE 2005-2009
34
University of Southern California
Center for Systems and Software Engineering
Open Account Use Case: Alternate Courses
•If the Customer did not provide a name, the system displays an error
message to that effect and prompts the Customer to type a name.
•If the Customer provided an email address that's not in the correct form,
the system displays an error message to that effect and prompts the
Customer to type a different address.
•If the Customer provided a password that is too short, the system
displays an error message to that effect and prompts the Customer to type
a longer password.
•If the Customer did not type the same password twice, the system
displays an error message to that effect and prompts the Customer to type
the password correctly the second time.
•If the account is already in the master account table, notify the user.
10/7/2009
© USC-CSSE 2005-2009
35
University of Southern California
Center for Systems and Software Engineering
Alternate Courses (cont.)
• A few slides back we suggested that there appear to be
five alternate courses.
• There are actually 25-1 = 31 alternate courses because:
– there are 5 independent binary outcomes that are under the
user’s control:
•
•
•
•
•
valid name vs. invalid name
valid email address vs. invalid email address
valid password vs. invalid password
identical passwords vs. non-identical passwords
new name and email address vs. name and email address
corresponding to existing account
– So, there are 25 = 32 different possible outcomes, only one of
which is the basic course
– So there are 31 different possible alternate courses
• But, when there are ‘N’ independent (sequentially tested)
binary outcomes then we will always write the alternate
courses as a list of N elements, each starting with an “if”.
10/7/2009
© USC-CSSE 2005-2009
36
University of Southern California
Center for Systems and Software Engineering
Alternate Courses (cont.)
• A serious cause of software development failure is
failure to identify and document all alternate courses
of every use case
• An equally serious cause of software development
failure is basic and alternate courses written in
incomplete / unclear / ambiguous English – or
whatever language is being used
• So, be very careful about these two issues and
review your work multiple times before considering it
to be done. (In teams, it would be best to have
multiple team members check for the two issues
listed above – IIV&V?)
10/7/2009
© USC-CSSE 2005-2009
37
University of Southern California
Center for Systems and Software Engineering
More on Use Cases
• In some approaches to OOA&D, use cases are at
a higher, less implementation-oriented level, than
the ones we’re using. (In some approaches use
cases almost look like restatements of the
requirements.)
• In the approach that we’ll be using:
– the GUI and the uses cases will be developed
iteratively, in parallel with one another
– and…the use cases will, if done properly, spell out, in
full clear detail, what happens for each possible type of
interaction that the actor can have with the application.
10/7/2009
© USC-CSSE 2005-2009
38
University of Southern California
Center for Systems and Software Engineering
Additional Internet Bookstore
Customer’s Use Cases
• On the following slides we show the basic and
alternative courses of the following two
additional Internet Bookstore customer use
cases, i.e., the:
– Log In use case
– Search by Author use case
10/7/2009
© USC-CSSE 2005-2009
39
University of Southern California
Center for Systems and Software Engineering
Log In Use Case
Basic Course
1. The Customer clicks the Log In button on the Home Page.
2. The System displays the Login Page.
3. The Customer enters his or her user ID and password and
then clicks the Log In button.
4. The system validates the login information against the
persistent Account data and then returns the Customer to
the Home Page.
10/7/2009
© USC-CSSE 2005-2009
40
University of Southern California
Center for Systems and Software Engineering
Log In Use Case: Alternate Courses
•If the Customer clicks the New Account button on the Login Page, the system
invokes the Open Account use case.
•If the Customer clicks the Reminder Word button on the Login Page, the
system displays the reminder word stored for that Customer, in a separate dialog
box. When the Customer clicks the OK button, the system returns the Customer
to the Login Page.
•If the Customer enters a user ID that the system does not recognize, the
system displays a message to that effect and prompts the Customer to either
enter a different ID or click the New Account button.
•If the Customer enters an incorrect password, the system displays a message
to that effect and prompts the Customer to reenter his or her password.
•If the Customer enters an incorrect password three times, the system
displays a page telling the Customer that he or she should contact customer
service, and also freezes the Login Page.
10/7/2009
© USC-CSSE 2005-2009
41
University of Southern California
Center for Systems and Software Engineering
Search by Author Use Case: Basic Course
1. The Customer types the name of an Author on the Search Page and
then clicks the Search button.
2. The system ensures that the Customer typed a valid search phrase, and
then searches the Catalog and retrieves all of the Books with which that
Author is associated.
3. The system then retrieves the important details about each Book, and
creates a Search Results object with that information.
4. Then the system displays the list of Books on the Search Results Page,
with the Books listed in reverse chronological order by publication date.
Each entry has a thumbnail of the Book's cover, the Book's title and
authors, the average Rating, and an Add to Shopping Cart button.
5. The Customer presses the Add to Shopping Cart button for a particular
Book.
6. The system passes control to the Add Item to Shopping Cart use case.
10/7/2009
© USC-CSSE 2005-2009
42
University of Southern California
Center for Systems and Software Engineering
Search by Author Use Case
Alternate Courses
•If the Customer did not type a search phrase before pressing the Search
button, the system displays an error message to that effect and prompts
the Customer to type a search phrase.
•If the system was unable to find any Books associated with the Author that
the Customer specified, the system displays a message to that effect and
prompts the Customer to perform a different search.
•If the Customer leaves the page in a way other than by pressing an Add to
Shopping Cart button, the system returns control to the use case from
which this use case received control.
10/7/2009
© USC-CSSE 2005-2009
43
University of Southern California
Center for Systems and Software Engineering
Use Cases in the SSAD
Use-case/ ‘Process’ description
Identifier
UC #
Purpose
<Purpose of this capability/use-case>
Requirements
<To which requirement it maps on to>
Development
Risks
<What are the possible ‘risks’ in developing this use case>
Pre-conditions
<Conditions that must hold true before this use case ‘executes’>
Post-conditions
<Conditions that hold true after the execution of the use-case>
Sequence of Actions – Basic/Alternate courses
Seq#
Actor’s Action
System’s Response
1
2
…
n
10/7/2009
© USC-CSSE 2005-2009
44
University of Southern California
Center for Systems and Software Engineering
GUI Prototyping
10/7/2009
© USC-CSSE 2005-2009
45
University of Southern California
Center for Systems and Software Engineering
GUI Prototyping – What?
• Based on the use-case descriptions you must come up
with a first-cut GUI Mockup/Prototype
• This ‘first-cut’ will explicitly show the intended layout of
the GUI – what all you intend to show and in what form
and how you lay it out
• It is extremely valuable to have GUI Design Principles be
a part of prototyping from day one – examples of these
were shown in the lecture on User Interfaces
• It is very likely that on seeing the GUI Mockups the
stakeholders realize what is missing or can think of new
features that the system should have. This could
influence the requirements and/or architecture!
10/7/2009
© USC-CSSE 2005-2009
46
University of Southern California
Center for Systems and Software Engineering
GUI Prototyping – Why?
• Helps early mitigation of the IKIWISI Risk (I’ll know it
when I’ll see it)
• The stakeholders get ‘early feedback’ as to what the
system will look like – along with early participation
• Remember User Interface (UI) is what the user sees
of the application and uses to interact with it
• This is ‘extremely’ iterative!
• Aesthetics NEED NOT be a part at this stage – but
can be so once the stakeholders have agreed to the
proposed UIs (usually done by UI Aesthetic experts!)
10/7/2009
© USC-CSSE 2005-2009
47
University of Southern California
Center for Systems and Software Engineering
GUI Prototyping – How?
• There are various approaches to ‘creating’ prototypes:
– Using tools such as iRise (recommended for web based
577 projects) or other commercial tools like
‘Balsamiq.com’ (the mockups shown a few slides back
were done using that)
– ‘Code’ it or use GUI Drag/Drop tools (Quite Common)
– PowerPoint/Visio (NOT scalable)
– Whiteboard techniques (Very tedious and requires
constant presence of stakeholder(s))
– Various ‘Imaging Tools’ i.e., Photoshop, Paintbrush
(Please DON’T try – extremely tedious!)
– Post-its?  Each can act as a UI Widget – has to be
augmented with the Whiteboard techniques
10/7/2009
© USC-CSSE 2005-2009
48
University of Southern California
Center for Systems and Software Engineering
Another Example
If there exists a User Interface, irrespective
of the device on which it will be displayed
you MUST prototype it (i.e., create early
mockups)
10/7/2009
© USC-CSSE 2005-2009
49
University of Southern California
Center for Systems and Software Engineering
GUI and Use-Cases
• When the GUIs get finalized (with a relatively
high level of confidence) the use-case text MUST
be refined too!
• The use-cases should then explicitly refer the
elements in the GUI Mockups
• Advantages:
– Helps make the English Use-case text descriptions
less ambiguous (almost negligible!) and more precise
– Developers are more aware of ‘what’ to build and what
is expected from the application
10/7/2009
© USC-CSSE 2005-2009
50
University of Southern California
Center for Systems and Software Engineering
How to build what to build?
• Currently we have seen how to reach towards
unambiguous (or less ambiguous) Use-case texts
• The use-case descriptions need to be ‘further
analyzed’ to identify what classes would become a
part of the analysis/design model
• These classes would already exist in part from the
Domain Model* and more would be identified as
result
• This ‘analysis’ is performed using an approach
known as Robustness Analysis which will be
covered in the next OOAD lecture
*The DM is thus ‘transformed’ into analysis/design classes and is NO longer called a DM
10/7/2009
© USC-CSSE 2005-2009
51