Software Engineering Discussion

> Select a mobile application you are familiar with, and assess it using the architecture considerations (economy, visibility, spacing, symmetry, emergence) from Pressman et al. (2020) Section 10.4. (attached chapter 10).

> What is a web app component?

> Chapter 13 has listed many quality attributes for mobile products. Select the 3 that you believe are most important, and make an argument that explains why each should be emphasized in mobile design work. (chapter 13 attached).

Need 3-4 pages with peer-reviewed citations. No introduction or conclusion needed.

264

C H A P T E R

13

What is it? Mobile design encompasses techni­
cal and nontechnical activities that include:
establishing the look and feel of the mobile
application (including mobile apps, WebApps,
virtual reality, and games), creating the aes­
thetic layout of the user interface, establish­
ing the rhythm of user interaction, defining
the overall architectural structure, develop­
ing the content and functionality that re­
side  within the architecture, and planning
the navigation that occurs within the mobile
product.

Who does it? Software engineers, graphic de­
signers, content developers, security special­
ists, and other stakeholders all participate in
the creation of a mobile design model.

Why is it important? Design allows you to cre­
ate a model that can be assessed for quality
and improved before content and code are
generated, tests are conducted, and end

users become involved in large numbers.
Design is the place where mobile app quality
is established.

What are the steps? Mobile design encom­
passes six major steps that are driven by

info

r­
mation obtained during requirements modeling
and are described in this chapter.

What is the work product? A design model
that encompasses content, aesthetics, archi­
tecture, interface, navigation, and component­
level design issues is the primary work product
that is produced during mobile design.

How do I ensure that I’ve done it right? Each
element of the design model is reviewed in an
effort to uncover errors, inconsistencies, or
omissions. In addition, alternative solutions
are considered, and the degree to which the
current design model will lead to effective
implementation on a variety of software plat­
forms and devices is also assessed.

Q u i c k L o o k

aesthetic design . . . . . . . . . . . . . . . . . . . . . . . 277
architecture design . . . . . . . . . . . . . . . . . . . . .278
challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
cloud computing . . . . . . . . . . . . . . . . . . . . . . .273
component-level design . . . . . . . . . . . . . . . . .282
content architecture . . . . . . . . . . . . . . . . . . . .279
content design . . . . . . . . . . . . . . . . . . . . . . . . . 277
content objects . . . . . . . . . . . . . . . . . . . . . . . . 277
context-aware apps . . . . . . . . . . . . . . . . . . . .274
design

best practices . . . . . . . . . . . . . . . . . . . . . . .285
mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . .272

pyramid . . . . . . . . . . . . . . . . . . . . . . . . . . .275
quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282

graphic design . . . . . . . . . . . . . . . . . . . . . . . . . 277
mobile architectures . . . . . . . . . . . . . . . . . . . .273
mobile development life cycle . . . . . . . . . . . .268
model-view-controller . . . . . . . . . . . . . . . . . . .279
navigation design . . . . . . . . . . . . . . . . . . . . . .280
quality checklist . . . . . . . . . . . . . . . . . . . . . . . .285
technical considerations . . . . . . . . . . . . . . . . .266
user interface design . . . . . . . . . . . . . . . . . . .270
WebApp architecture . . . . . . . . . . . . . . . . . . .279

k e y
c o n c e p t s

Design
for Mobility

Mobile devices—smartphones, tablets, wearable devices, handheld gaming
devices, and other specialized products—have become the new face of comput-
ing. According to Pew Research Center [Pew18], in the United States 77 percent
of people own a smartphone and 50 percent of people own a tablet computer of
some kind. Mobile computing has become a dominant force.

CHAPTER 13 DESIGN FOR MOBILITY 265

In his authoritative book on Web design, Jakob Nielsen [Nie00] states: “There are
essentially two basic approaches to design: the artistic ideal of expressing yourself
and the engineering ideal of solving a problem for a customer.” During the first decade
of mobile development, the artistic idea was the approach that many developers chose.
Design occurred in an ad hoc manner and was usually conducted as HTML was
generated. Design evolved out of an artistic vision that evolved as Web page construc-
tion occurred.

Even today, many developers use mobile apps as poster children for “limited
design.” They argue that immediacy and volatility of the mobile market mitigate
against formal design; that design evolves as an application is built (coded), and that
relatively little time should be spent on creating a detailed design model. This argu-
ment has merit, but only for relatively simple apps. When content and function are
complex; when the size of the mobile app encompasses hundreds or thousands of
content objects, functions, and analysis classes; and when the success of the app will
have a direct impact on the success of the business, design cannot and should not be
taken lightly. This reality leads us to Nielsen’s second approach—“the engineering
ideal of solving a problem for a customer.”

13.1 th e ch a L L e ng e s

Although mobile devices have many features in common with each other, their users
often have very different perceptions of what features they expect to be bundled in
each. Some users expect the same features that are provided on their personal comput-
ers. Others focus on the freedom that portable devices give them and gladly accept
the reduced functionality in the mobile version of a familiar software product. Still
others expect unique experiences not possible on traditional computing or entertain-
ment devices. The user’s perception of “goodness” might be more important than any
of the technical quality dimensions of the mobile product itself.

13.1.1 Development Considerations
Like all computing devices, mobile platforms are differentiated by the software they
deliver—a combination of operating system (e.g., Android or iOS) and a small sub-
set of the hundreds of thousands of mobile software products that provide a very
wide range of functionality. New tools allow individuals with little formal training
to create and sell apps alongside other apps developed by large teams of software
developers.

Even though apps can be developed by amateurs, many software engineers think
that MobileApps are among the most challenging software systems being built today
[Voa12]. Mobile platforms are very complex. Both the Android and iOS operating
systems contain over 12 million lines of code. Mobile devices often have mini brows-
ers that will not display the full set of content available on a Web page. Different
mobile devices use different operating systems and platform-dependent development
environments. Mobile devices tend to have smaller screen sizes and more varied
screen sizes than personal computers. This may require greater attention to user inter-
face design issues, including decisions to limit display of some content. MobileApps

266 PART TWO MODELING

must be designed to take intermittent connectivity outages into account, limitations
on battery life, and other device constraints1 [Whi08].

System components in mobile computing environments are likely to change their
locations while their apps are running. To maintain connectivity in nomadic net-
works,2 coordination mechanisms for discovering devices, exchanging information,
maintaining security and communication integrity, and synchronizing actions must be
developed. There is always a trade-off between security and other elements of the
mobile product design.

In addition, software engineers must identify the proper design trade-offs between
the expressive power of the MobileApp and stakeholder security concerns. Developers
must seek to discover algorithms (or adapt existing algorithms) that are energy effi-
cient to conserve battery power when possible. Middleware may have to be created
to allow different types of mobile devices to communicate with each other in the same
mobile networks [Gru00].

Software engineers should craft a user experience that takes advantage of device
characteristics and context-aware applications. The nonfunctional requirements (e.g.,
security, performance, usability) are a bit different from those for either WebApps or
desktop software applications. There is always a trade-off between security and other
elements of the mobile design. Testing mobile software products (Chapter 21) pro-
vides additional challenges because users expect that they will work in a large number
of physically different environments. Portability is another challenge for software engi-
neers as there are several popular device platforms. It is expensive to develop and
support applications for multiple device platforms [Was10].

13.1.2 Technical Considerations
The low cost of adding Web capabilities to everyday devices such as phones, cameras,
and TVs is transforming the way people access information and use network services
[Sch11]. Among the many technical considerations that MobileApps should address
are the following:

Multiple hardware and software platforms. It is not at all unusual for a
mobile product to run on many different platforms (both mobile and station-
ary) with a range of differing levels of functionality. The reasons for these
differences are in part because the hardware and software available are quite
different from device to device. This increases both development cost and
time. It also can make configuration management (Chapter 22) more
difficult.
Many development frameworks and programming languages. Mobile
products are currently being written in several distinct programming or script-
ing languages (e.g., HTML5, JavaScript, Java, Swift, and C#) for a multitude
of popular development frameworks (e.g., Android, iOS, Xamarin, Windows,
AngularJS). Very few mobile devices allow direct development on a device
itself. Instead, mobile developers typically use emulators running on desktop

1 Available at http://www.devx.com/SpecialReports/Article/37693.
2 Nomadic networks have changing connections to mobile devices or servers.

CHAPTER 13 DESIGN FOR MOBILITY 267

development systems. These emulators may or may not accurately reflect the
limitations of the device itself. Thin-client applications are often easier to port
to multiple devices than applications designed to run exclusively on the
mobile device.
Many app stores with different rules and tools. Each mobile platform has
its own app store and its own standards for accepting apps (e.g., Apple,3
Google,4 Microsoft,5 and Amazon6 publish their own standards). Development
of a mobile product for multiple platforms must proceed separately, and each
version of the app needs its own standards expert.
Very short development cycles. The marketplace for mobile products is
very competitive, and software engineers are likely to make use of agile
development processes when building MobileApps in an effort to reduce
development time [Was10].
User interface limitations and complexities of interaction with sensors and
cameras. Mobile devices have smaller screen sizes than personal computers
and a richer set of interaction possibilities (touch, gesture, camera, etc.) and
usage scenarios based on context awareness. The style and appearance of the
user interface is often dictated by the nature of platform-specific development
tools [Rot02]. Allowing smart devices to interact with smart spaces offers the
potential to create personalized, networked, high-fidelity application platforms
such as those seen by merging smartphones and car infotainment systems.7

Effective use of context. Users expect MobileApps to deliver personalized
user experiences based on the physical location of a device in relation to the
available network features. User interface design and context-aware applica-
tions are discussed in greater detail in Section 13.4.
Power management. Battery life is often one of the most limiting constraints
on many mobile devices. Backlighting, reading and writing to memory, using
wireless connections, making use of specialized hardware, and processor speed all
impact power usage and need to be considered by software developers [Mei09].
Security and privacy models and policies. Wireless communication is dif-
ficult to protect from eavesdropping. Preventing man-in-the-middle-attacks8 in
automotive applications can be critical to the safety of the users [Bos11].
Data stored on a mobile device are subject to theft if a device is lost or a
malicious app is downloaded. Software policies that increase the level of con-
fidence in the security and privacy of a MobileApp often reduce the usability
of the app and the spontaneity of the communication among users [Rot02].

3 https://developer.apple.com/appstore/guidelines.html.
4 http://developer.android.com/distribute/googleplay/publish/preparing.html.
5 http://msdn.microsoft.com/en-us/library/ff941089%28v=vs.92%29.aspx.
6 https://developer.amazon.com/apps-and-games/app-submission/android.
7 When used in an automotive setting, smart devices should be able to restrict access to

services that may distract the driver and allow hands-free operation when a vehicle is
moving [Bos11].

8 These attacks involve a third party intercepting communications between two trusted sources
and impersonating one or both of the parties.

268 PART TWO MODELING

Computational and storage limitations. There is great interest in using
mobile devices to control home environmental and security services. When
MobileApps are allowed to interact with devices and services in their environ-
ment, it is easy to overwhelm the mobile device (storage, processing speed,
power consumed) with the sheer volume of information [Spa11]. Developers
may need to look for programming shortcuts and means of reducing the
demands made on processor and memory resources.
Applications that depend on external services. Building thin mobile
clients suggests the need to rely on Web service providers and cloud storage
facilities. This increases concerns for both data or service accessibility
and security [Rot02].
Testing complexity. Mobile products that run entirely on the device can be
tested using traditional software testing methods (Chapters 19 and 20) or
using emulators running on personal computers. Thin-client MobileApps are
particularly challenging to test. They exhibit many of the same testing chal-
lenges found in WebApps, but they have the additional concerns associated
with transmission of data through Internet gateways and telephone networks
[Was10]. Testing of mobile software products will be discussed in
Chapter 21.

13.2 Mo b i L e De v e L o p M e n t Li f e cyc L e

Burns [Bur16] and her Microsoft colleagues describe a recommendation for an
iterative mobile SDLC that contains five major stages:

Inception. Goals, features, and functions of the mobile product are identified to
determine the scope and the size of the first increment or feasibility prototype.
Developers and stakeholders must be conscious of human, social, cultural, and
organizational activities that may reveal hidden aspects of the users’ needs and
affect the business targets and functionality of the proposed mobile product.

Design. The design includes architectural design, navigation design, interface
design, content design. Developers define the app user experience using screen
mockups and paper prototypes to help create a proper user interface design that will
take different screen sizes and capabilities into account as well as the capabilities of
each targeted platform.

Development. Mobile software is coded, functional and nonfunctional. Test
cases are created and executed, and usability and accessibility evaluations are con-
ducted as the product evolves.

Stabilization. Most mobile products go through a series of prototypes: feasibility
prototype, intended as a proof of concept with perhaps only one complete logic
path through the application; alpha prototype, which contains the functionality for
minimum viable product; beta prototype, which is largely complete and contains
most tested functionality; and lastly the release candidate, which contains all
required functionality, for which all scheduled tests have been completed, and
which is ready for review by the product owner.

CHAPTER 13 DESIGN FOR MOBILITY 269

Deployment. Once stabilized, a mobile product is reviewed by a commercial app
store and made available for sale and download. For apps intended for internal com-
pany use only, a product owner review may be all that is required before deployment.

Mobile development makes use of an agile, spiral engineering process model. The
stages are not completed in order like they would be if mobile development was done
using the waterfall model. The stages described above are visited repeatedly as developers
and stakeholders gain better understanding of the user needs and product business goals.

Formulating Mobile Device Requirements

The scene: A meeting room.
The first meeting to identify

requirements for a mobile version of the
SafeHome WebApp.

The players: Jamie Lazar, software team
member; Vinod Raman, software team mem­
ber; Ed Robbins, software team member; Doug
Miller, software engineering manager; three
members of marketing; a product engineering
representative; and a facilitator.

The conversation:
Facilitator (pointing at whiteboard): So that’s
the current list of objects and services for the
home security function present in the WebApp.

Vinod (interrupting): My understanding is
that people want SafeHome functionality
to be accessible from mobile devices as
well . . . including the home security function?

Marketing person: Yes, that’s right . . . we’ll
have to add that functionality and try to make it
context aware to help personalize the user
experience.

Facilitator: Context aware in what sense?

Marketing person: People might want to use
a smartphone instead of the control panel and
avoid logging on to a website when they are in
the driveway at home. Or they might not want
all family members to have access to the mas­
ter control dashboard for the system from
their phones.

Facilitator: Do you have specific mobile
devices in mind?

Marketing person: Well, all smartphones
would be nice. We will have a Web version
done, so won’t the MobileApp run on all of
them?

Jamie: Not quite. If we took a mobile phone
browser approach, we might be able to
reuse a lot of our WebApp functionality. But
remember, smartphone screen sizes vary,
and they may or may not all have the same
touch capabilities. So, at the very least we
would have to create a mobile website that
takes the features of each device into
account.

Ed: Perhaps we should build the mobile
version of the website first.

Marketing person: OK, but a mobile website
solution wasn’t what we had in mind.

Vinod: Each mobile platform seems to
have its own unique development environ­
ment, too.

Production rep: Can we restrict MobileApp
development to only one or two types of
smartphones?

Marketing person: I think that might work.
Unless I’m mistaken, the smartphone market
is dominated by two smartphone platforms
right now.

Jamie: There’s also security to worry about.
We better make sure an outsider can’t hack
into the system, disarm it, and rob the place or
worse. Also, a phone could get lost or stolen
more easily than a laptop.

safehoMe

270 PART TWO MODELING

13.2.1 User Interface Design
Mobile device users expect that minimal learning time will be required to master a
MobileApp. To achieve this, MobileApp designers use consistent icon representations
and placement across multiple platforms. In addition, designers must be sensitive to
the user’s expectation of privacy with regard to the display of personal information
on the screen of the mobile device. Touch and gesture interfaces, along with sophis-
ticated voice input and facial recognition, are maturing rapidly [Shu12] and have
already become part of the user interface designer’s toolbox.

Legal and ethical pressure to provide for access by all persons suggests that mobile
device interfaces need to account for brand differences, cultural differences, differ-
ences in computing experience, elderly users, and users with disabilities (e.g., visual,
aural, mobility). The effects of poor usability may mean that users cannot complete
their tasks or will not be satisfied with the results. This suggests the importance of
user-centered design activities in each of the usability areas (user interface, external
accessory interface, and service interface). Accessibility is an important design issue
and must be considered when user-centered design is applied.

In trying to meet stakeholder usability expectations, MobileApp developers should
attempt to answer these questions to assess the out-of-the-box readiness of the device:

∙ Is the user interface consistent across applications?
∙ Is the device interoperable with different network services?
∙ Is the device acceptable in terms of stakeholder values9 in the target market area?

Eisenstein [Eis01] claims that the use of abstract, platform-neutral models to describe
a user interface greatly facilitates the development of consistent, usable multiplatform
user interfaces for mobile devices. Three models in particular are useful. A platform
model describes the constraints imposed by each platform to be supported. A presen-
tation model describes the appearance of the user interface. The task model is a structured
representation of the tasks a user needs to perform to meet her task goals. In the best
case, model-based design (Chapter 9) involves the creation of databases that contain the

9 Brand, ethical preferences, moral preferences, cognitive beliefs.

Doug: Very true.

Marketing: But we still need the same level of
security . . . just also be sure to stop an out­
sider from getting in with a stolen phone.

Ed: That’s easier said than done and . . .

Facilitator (interrupting): Let’s not worry
about those details yet.

(Doug, serving as the recorder for the meeting,
makes an appropriate note.)

Facilitator: As a starting point, can we identify
which elements of WebApp security function
are needed in the MobileApp and which will
need to be newly created? Then we can de­
cide how many mobile platforms we can sup­
port and when we can move forward on this
project.

(The group spends the next 20 minutes
refining and expanding the details of the home
security function.)

CHAPTER 13 DESIGN FOR MOBILITY 27

1

models and has tool support for generating user interfaces for multiple devices auto-
matically. Utilizing model-based design techniques can also help designers recognize
and accommodate the unique contexts and context changes that are present in mobile
computing. Without an abstract description of a user interface, the development of
mobile user interfaces can be error prone and time consuming.

13.2.2 Lessons Learned
de Sá and Carriço [Des08] contend that there are important differences between develop-
ing conventional software and developing mobile applications. Software engineers cannot
continue to use the same conventional techniques they have used and expect them to be
successful. They suggest three approaches for the design of mobile applications:

Usage Scenarios. Described in Chapter 12, usage scenarios must consider context
variables (location, user, and device) and transitions between contextual scenarios
(e.g., user moves from bedroom to kitchen or switches from stylus to a finger). de Sá
and Carriço have identified a set of scenario-variable types that should be considered
in developing the user scenarios—locations and settings, movement and posture,
devices and usages, workloads and distractions, user preferences.

Mobile User Interface
Design Considerations
Design choices affect performance and

should be examined early in the user interface de­
sign process. Ivo Weevers [Wee11] posted several
mobile user–interface design practices that have
proven to be helpful when designing mobile
applications:

∙ Define user interface brand signatures.
Differentiate the app from its competitors.
Make the core signature elements of the
brand the most responsive, because users
will use them over and over.

∙ Focus the portfolio of products. Target the
platforms that are most important to the
success of the app and the company. Not all
platforms have the same number of users.

∙ Identify the core user stories. Make use
of techniques that require stakeholders to
prioritize their needs as a way to reduce a
lengthy list of requirements and to consider
the constrained resources available on
mobile devices.

∙ Optimize user interface flows and elements.
Users do not like to wait. Identify potential
bottlenecks in user work flow and make sure
the user is given an indication of progress
when delays occur. Make sure that the time to
display screen elements is justified in terms of
user benefits.

∙ Define scaling rules. Determine the options
that will be used when information to be
displayed is too large to fit on the screen. Man­
aging functionality, aesthetics, usability, and
performance is a continual balancing act.

∙ User performance dashboard. The dashboard
is used to communicate the product’s current
state of completion (e.g., number of use stories
implemented), its performance relative to
its targets, and perhaps comparisons to its
competitors.

∙ Champion-dedicated user interface engineer-
ing skills. It is important to understand that the
implementation of layout, graphics, and anima­
tion has performance implications. Techniques
to interleave rendering of display items and
program execution can be helpful.

info

272 PART TWO MODELING

Ethnographic Observation.10 This is a widely used method for gathering informa-
tion about representative users of a software product as it is being designed. It is often
difficult to observe users as they change contexts, because the observer must follow
users for long periods of time, something that could raise privacy concerns.11 A com-
plicating factor is that users seem to complete tasks differently in private settings than
in social settings. The same users may need to be observed performing tasks in mul-
tiple contexts while monitoring transitions, as well as recording user reactions to the
changes.

Low-Fidelity Paper Prototypes (e.g., cards or Post-it notes). This is a cost-effective
usability assessment approach in user interface design that can be used before any
programming takes place. It is important for these prototypes to be similar in size and
weight and for their use to be allowed in a variety of contexts. It is also important
that the sketches or text displays be true to size and for the final product to be of high
quality. Placement and size of user interface widgets (e.g., buttons or scrollbars) must
be designed so that they will not disappear when users extend their screens by
zooming. The interaction type (e.g., stylus, joy stick, touch screen) needs to be emu-
lated in the low-fidelity prototype (e.g., colored pen or push pin) to check placement
and ease of use. Later prototypes may then be created to run on the targeted mobile
devices once the layout and placement issues have been resolved.

MobileApp Design Mistakes
Joh Koester [Koe12] posts several
examples of mobile design practices

that should be avoided:
∙ Kitchen sink. Avoid adding too many features

to the app and too many widgets on the screen.
Simple is understandable. Simple is marketable.

∙ Inconsistency. To avoid this, set standards
for page navigation, menu use, buttons, tabs,
and other user­interface elements. Stick to a
uniform look and feel.

∙ Overdesigning. Be ruthless when designing
apps. Remove unnecessary elements and
wasteful graphics. Do not be tempted to add
elements just because you think you should.

∙ Lack of speed. Users do not care about device
constraints—they want to view things quickly.
Preload what you can. Eliminate what is not
needed.

∙ Verbiage. Unnecessarily long, wordy
menus and screen displays are indications
of a mobile product that has not been
tested with users and developers who have
not spent enough time understanding the
user’s task.

∙ Nonstandard interaction. One reason for
targeting a platform is to take advantage of
the user’s experience with the way things are
done on that platform. Where standards exist
use them. This needs to be balanced with the
need to have an application appear and be­
have the same way on multiple devices when
possible.

∙ Help-and-FAQ-itis. Adding online help is not
the way to repair a poorly designed user inter­
face. Make sure you have tested your app with
your targeted users and repaired the identified
defects.

info

10 Ethnographic observation is a means determining the nature of user tasks by watching users
in their work environment.

11 Asking users to fill out anonymous questionnaires may have to suffice when direct observa-
tion is not possible.

CHAPTER 13 DESIGN FOR MOBILITY 273

13.3 Mo b i L e arc h i t e c t u r e s

Services computing12 and cloud computing13 enable the rapid development of large-
scale distributed applications based on innovative architectural designs [Yau11]. These
two computing paradigms have made it easier and more economical to create applica-
tions on many different mobile devices (e.g., laptop computers, smartphones, and
tablets). These two paradigms allow resource outsourcing and transfer of information
technology management to service providers while at the same time mitigating the
impact of resource limitations on some mobile devices. A service-oriented architecture
provides the architectural style (e.g., REST),14 standard protocols (e.g., XML15 and
SOAP16), and interfaces (e.g., WSDL)17 needed for mobile development. Cloud com-
puting enables convenient, on-demand network access to a shared pool of configurable
computing resources (servers, storage, applications, and services).

Service computing allows mobile developers to avoid the need to integrate service
source code into the client running on a mobile device. Instead, the service runs out
of the provider’s server and is loosely coupled with the applications that make use of
it through messaging protocols. A service typically provides an application program-
ming interface (API) to allow it to be treated like an abstract black box.

Cloud computing lets the client (either a user or program) request computing capa-
bilities as needed, across network boundaries anywhere or any time. The cloud archi-
tecture has three layers, each of which can be called as a service (Figure 13.1). The
software as service layer consists of software components and applications hosted by
third-party service providers. The platform as service layer provides a collaborative
development platform to assist with design, implementation, and testing by geograph-
ically distributed team members. Infrastructure as a service provides virtual comput-
ing resources (storage, processing power, network connectivity) on the cloud.

Mobile devices can access cloud services from any location at any time. The risks of
identity theft and service hijacking require providers of mobile services and cloud comput-
ing to employ rigorous security engineering techniques (Chapter 18) to protect their users.

Taivalsaari [Tai12] points out that making use of cloud storage can allow any
mobile device or software features to be updated easily on millions of devices world-
wide. In fact, it is possible to virtualize the entire mobile user experience so that all
applications are downloaded from the cloud.

12 Services computing focuses on architectural design and enables application development
through service discovery and composition.

13 Cloud computing focuses on the effective delivery of services to users through flexible and
scalable resource virtualization and loading balancing.

14 Representation State Transfer describes a networked Web architectural style where the
resource representation (e.g., a Web page) places the client in a new state. The client changes
or transfers state with each resource representation.

15 Extensible Markup Language (XML) is designed to store and transport data, while HTML
is designed to display data.

16 Simple Object Access Protocol is a specification for exchanging structured information in
the implementation of Web services in computer networks.

17 Web Services Description Language is an XML-based language for describing Web services
and how to access them.

274 PART TWO MODELING

13.4 co n t e x t-awa r e ap p s

Context allows the creation of new applications based on the location of the mobile
device and the functionality to be delivered by the device. Context can also help
tailor personal computer applications for mobile devices (e.g., downloading patient
information to a device carried by a home health care worker as he arrives at the
patient’s house).

Using highly adaptive, contextual interfaces is a good way to deal with device
limitations (e.g., screen size and memory). To facilitate the development of context-
aware user interaction requires the support of corresponding software architectures.

In an early discussion of context-aware applications, Rodden [Rod98] points out
that mobile computing merges the real and virtual world by providing functionality
that allows a device to be aware of its location, time, and other objects in its sur-
roundings. The device could be in a fixed location like an alarm sensor, embedded in
an autonomous device, or be carried around by a human. Because the device can be
designed to be used by individuals, groups, or the public, it must detect the presence
and identity of the user, as well as the attributes of the context that are relevant or
permitted for that user (even if the user is another device).

To achieve context awareness, mobile systems must produce reliable information
in the presence of uncertain and rapidly changing data from a variety of heterogeneous
sources. Extracting relevant context information by combing data from several sensors
proves challenging because of problems with noise, miscalibration, wear and tear, and
weather. Event-based communication is preferable to the management of continuous
streams of high-abstraction-level data in context-aware applications [Kor03].

Figure 13.1
Cloud
computing
layers

More Control

Less Control

SaaSSoftware as a Service
End Users

PaaSPlatform as a Service
Application Developers

IaaSInfrastructure as a Service
Network Architects

CHAPTER 13 DESIGN FOR MOBILITY 275

In ubiquitous computing environments, multiple users work with a wide range of
different devices. The configuration of the devices should be flexible enough to
change frequently because of the demands of mobile work practices. It is important
for the software infrastructure to support different styles of interaction (e.g., gestures,
voice, and pen) and store them in abstractions that can be shared easily.

There are times when one user may desire to work with more than one device
simultaneously on the same product (e.g., use a touch-screen device to edit a docu-
ment image and a personal keyboard to edit document text). It is challenging to
integrate mobile devices that are not always connected to the network and have a
variety of device constraints [Tan01]. Networked, multiplayer games have had to deal
with these problems by storing the game state on each device and sharing change
information among other game players’ devices in real time.

13.5 we b De s i g n py r a M i D

What is design in the context of Web engineering? This simple question is more dif-
ficult to answer than one might believe. Pressman and Lowe [Pre08] discuss this when
they write:

The creation of an effective design will typically require a diverse set of skills. Some-
times, for small projects, a single developer may need to be multi-skilled. For larger
projects, it may be advisable and/or feasible to draw on the expertise of specialists: Web
engineers, graphic designers, content developers, programmers, database specialists,
information architects, network engineers, security experts, and testers. Drawing on these
diverse skills allows the creation of a model that can be assessed for quality and improved
before content and code are generated, tests are conducted, and end-users become
involved in large numbers. If analysis is where WebApp quality is established, then design
is where the quality is truly embedded.

The appropriate mix of design skills will vary depending upon the nature of the
WebApp. Figure 13.2 depicts a design pyramid for WebApps. Each level of the
pyramid represents a design action that is described in the sections that follow.

13.5.1 WebApp Interface Design
When a user interacts with a computer-based system, a set of fundamental principles
and overriding design guidelines apply. These have been discussed in Chapter 12.18
Although WebApps present a few special user interface design challenges, the basic
principles and guidelines are applicable.

One of the challenges of interface design for WebApps is the indeterminate nature
of the user’s entry point. That is, the user may enter the WebApp at a “home” location
(e.g., the home page) or may be linked into some lower level of the WebApp archi-
tecture. In some cases, the WebApp can be designed in a way that reroutes the user
to a home location, but if this is undesirable, the WebApp design must provide inter-
face navigation features that accompany all content objects and are available regardless
of how the user enters the system.

18 Section 12.1 is dedicated to the user interface design portion of user experience design. If
you have not already done so, read it at this time.

276 PART TWO MODELING

The objectives of a WebApp interface are to: (1) establish a consistent window
into the content and functionality provided by the interface, (2) guide the user through
a series of interactions with the WebApp, and (3) organize the navigation options and
content available to the user. To achieve a consistent interface, you should first use
visual design (Section 12.1) to establish a coherent “look.” This encompasses many
characteristics but must emphasize the layout and form of navigation mechanisms. To
guide user interaction, you may draw on an appropriate metaphor19 that enables the
user to gain an intuitive understanding of the interface. To implement navigation
options, you can select navigation menus positioned consistently on Web pages,
graphic icons represented in a manner that enable a user to recognize that the icon is
a navigation element, and/or graphic images that provide a link to a content object or
WebApp functionality. It is important to note that one or more of these navigation
mechanisms should be provided at every level of the content hierarchy.

Every Web page has a limited amount of “real estate” that can be used to support
nonfunctional aesthetics, navigation features, informational content, and user-directed
functionality. The development of this real estate is planned during aesthetic design.

technology

user
Figure 13.2

A design
pyramid for
WebApps

19 In this context, a metaphor is a representation (drawn from the user’s real-world experience)
that can be modeled within the context of the interface. A simple example might be a slider
switch that is used to control the auditory volume of an .mp4 file.

CHAPTER 13 DESIGN FOR MOBILITY 277

13.5.2 Aesthetic Design
Aesthetic design, also called visual design or graphic design, is an artistic endeavor
that complements the technical aspects of WebApp design. We discussed visual design
in Section 12.1.4. Page layout is one aspect of aesthetic design that can affect the
usefulness (and usability) of a WebApp.

There are no absolute rules when a Web page layout is designed. However, a
number of general layout guidelines are worth considering:

Don’t be afraid of open space. It is inadvisable to pack every square inch
of a Web page with information. The resulting clutter makes it difficult for
the user to identify needed information or features and create visual chaos
that is not pleasing to the eye.
Emphasize content. After all, that’s the reason the user is there. Nielsen
[Nie00] suggests that the typical Web page user should be 80 percent content
with the remaining real estate dedicated to navigation and other features.
Organize layout elements from top left to bottom right. The vast major-
ity of users will scan a Web page in much the same way as they scan the
page of a book—top left to bottom right.20 If layout elements have specific
priorities, high-priority elements should be placed in the upper-left portion of
the page real estate.
Group navigation, content, and function geographically within the page.
Humans look for patterns in virtually all things. If there are no discernible
patterns within a Web page, user frustration is likely to increase (owing to
unnecessary searching for needed information).
Don’t extend your real estate with the scrolling bar. Although scrolling is
often necessary, most studies indicate that users would prefer not to scroll. It
is often better to reduce page content or to present necessary content on
multiple pages.
Consider resolution and browser window size when designing layout.
Rather than defining fixed sizes within a layout, the design should specify all
layout items as a percentage of available space [Nie00]. With the growing use
of mobile devices with different screen sizes, this concept becomes increas-
ingly important.

13.5.3 Content Design
We introduced content design in Section 12.1.1. In WebApp design, a content object
is more closely aligned with a data object for traditional software. A content object
has attributes that include content-specific information (normally defined during
WebApp requirements modeling) and implementation-specific attributes that are spec-
ified as part of design.

As an example, consider an analysis class, ProductComponent, developed for the
SafeHome e-commerce system. The analysis class attribute, description, is represented

20 There are exceptions that are cultural and language based, but this rule holds for most users.

278 PART TWO MODELING

as a design class named CompDescription composed of five content objects:
MarketingDescription, Photograph, TechDescription, Schematic, and Videos shown
as the bottom row of shaded objects noted in Figure 13.3. Information contained within
the content object is noted as attributes. For example, Photograph (a jpg image) has
the attributes horizontal dimension, vertical dimension, and border style.

UML association and an aggregation21 may be used to represent relationships
between content objects. For example, the UML association shown in Figure 13.3
indicates that one CompDescription is used for each instance of the ProductCom-
ponent class. CompDescription is composed on the five content objects shown. How-
ever, the multiplicity notation shown indicates that Schematic and Videos are optional
(zero occurrences are possible), one MarketingDescription and one TechDescription
are required, and one or more instances of Photograph are used.

13.5.4 Architecture Design
Architecture design is tied to the goals established for a WebApp, the content to be
presented, the users who will visit, and the navigation philosophy that has been estab-
lished. As an architectural designer, you must identify content architecture and

text color
font style
font size
line spacing
text usage size
background color

MarketingDescription

text color
font style
font size
line spacing
text usage size
background color

TechDescription

horizontal dimension
vertical dimension
border style

audio volume

Videos

horizontal dimension
vertical dimension
border style

Schematic

horizontal dimension
vertical dimension
border style

Photograph

partNumber
partName
partType
description
price

createNewItem()
displayDescription()
displayTechSpec

ProductComponent CompDescription

Sensor Camera

1 Is part of

1 1..*

0..1

0..1

0..1 1

1

1

Control Panel SoftFeature

Figure 13.3 Design representation of content objects

21 Both of these representations are discussed in Appendix 1.

CHAPTER 13 DESIGN FOR MOBILITY 279

WebApp architecture. Content architecture22 focuses on the manner in which content
objects (or composite objects such as Web pages) are structured for presentation and
navigation. WebApp architecture addresses the manner in which the application is
structured to manage user interaction, handle internal processing tasks, effect naviga-
tion, and present content.

In most cases, architecture design is conducted in parallel with interface design,
aesthetic design, and content design. Because the WebApp architecture may have a
strong influence on navigation, the decisions made during this design action will
influence work conducted during navigation design.

WebApp architecture describes an infrastructure that enables a Web-based system
or application to achieve its business objectives. Jacyntho and his colleagues [Jac02b]
describe the basic characteristics of this infrastructure in the following manner:

Applications should be built using layers in which different concerns are taken into
account; in particular, application data should be separated from the page’s contents
(navigation nodes) and these contents, in turn, should be clearly separated from the
interface look-and-feel (pages).

The authors suggest a three-layer design architecture that decouples the interface
from navigation and from application behavior. They argue that keeping the interface,
application, and navigation separate simplifies implementation and enhances reuse.

The Model-View-Controller (MVC) architecture [Kra88]23 is a popular WebApp
architectural model that decouples the user interface from the WebApp functionality
and information content. The model (sometimes referred to as the “model object”)
contains all application-specific content and processing logic, including all content
objects, access to external data/information sources, and all processing functionality
that is application specific. The view contains all interface-specific functions and
enables the presentation of content and processing logic, including all content objects,
access to external data and information sources, and all processing functionality
required by the end user. The controller manages access to the model and the view
and coordinates the flow of data between them. In a WebApp, “the view is updated
by the controller with data from the model based on user input” [WMT02]. A sche-
matic representation of the MVC architecture is shown in Figure 13.4.

Referring to the figure, user requests or data are handled by the controller. The
controller also selects the view object that is applicable based on the user request.
Once the type of request is determined, a behavior request is transmitted to the model,
which implements the functionality or retrieves the content required to accommodate
the request. The model object can access data stored in a corporate database, as part
of a local data store, or as a collection of independent files. The data developed by
the model must be formatted and organized by the appropriate view object and then
transmitted from the application server back to the client-based browser for display
on the customer’s machine.

22 The term information architecture is also used to connote structures that lead to better
organization, labeling, navigation, and searching of content objects.

23 It should be noted that MVC is actually an architectural design pattern developed for the
Smalltalk environment (see www.smalltalk.org) and can be used for any interactive
application.

280 PART TWO MODELING

In many cases, WebApp architecture is defined within the context of the develop-
ment environment in which the application is to be implemented. If you have further
interest, see [Fow03] for a discussion of development environments and their role in
the design of Web application architectures.

13.5.5 Navigation Design
Once the WebApp architecture has been established and the components (pages,
scripts, applets, and other processing functions) of the architecture have been iden-
tified, you must define navigation pathways that enable users to access WebApp
content and functions. To accomplish this, identify the semantics of navigation for
different users of the site, and define the mechanics (syntax) of achieving the
navigation.

Like many WebApp design actions, navigation design begins with a consideration
of the user hierarchy and related use cases (Chapter 8) developed for each category
of user (actor). Each actor may use the WebApp somewhat differently and therefore
have different navigation requirements. In addition, the use cases developed for each
actor will define a set of classes that encompass one or more content objects or
WebApp functions. As each user interacts with the WebApp, she encounters a series
of navigation semantic units (NSUs)—“a set of information and related navigation
structures that collaborate in the fulfillment of a subset of related user requirements”
[Cac02]. An NSU describes the navigation requirements for each use case. In
essence, the NSU shows how an actor moves between content objects or WebApp
functions.

An NSU is composed of a set of navigation elements called ways of navigating
(WoN) [Gna99]. A WoN represents the best navigation pathway to achieve a naviga-
tional goal for a specific type of user. Each WoN is organized as a set of navigational
nodes (NN) that are connected by navigational links. In some cases, a navigational
link may be another NSU. Therefore, the overall navigation structure for a WebApp
may be organized as a hierarchy of NSUs.

View

Model Controller

NotifiesWrites

Updates

Fills

Figure 13.4
The MVC
architecture

CHAPTER 13 DESIGN FOR MOBILITY 281

To illustrate the development of an NSU, consider the use case Select SafeHome
Components:

Use Case: Select SafeHome Components

The WebApp will recommend product components (e.g., control panels, sensors,
cameras) and other features (e.g., PC-based functionality implemented in software)
for each room and exterior entrance. If I request alternatives, the WebApp will pro-
vide them, if they exist. I will be able to get descriptive and pricing information for
each product component. The WebApp will create and display a bill-of-materials as
I select various components. I’ll be able to give the bill-of-materials a name and
save it for future reference (see use case Save Configuration).

The underlined items in the use case description represent classes and content
objects that will be incorporated into one or more NSUs that will enable a new
customer to perform the scenario described in the Select SafeHome Components
use case.

Figure 13.5 depicts a partial semantic analysis of the navigation implied by the
Select SafeHome Components use case. Using the terminology introduced earlier,
the figure also represents a way of navigating (WoN) for the SafeHomeAssured.com
WebApp. Important problem domain classes are shown, along with selected content
objects (in this case the package of content objects named CompDescription, an
attribute of the ProductComponent class). These items are navigation nodes. Each
of the arrows represents a navigation link24 and is labeled with the user-initiated action
that causes the link to occur.

24 These are sometimes referred to as navigation semantic links (NSLs) [Cac02].

CompDescription
MarketingDescription

techDescription

Schematic Photograph

Video

ProductComponent

BillOfMaterials

Room

select Room

<>
view BillOfMaterials

<>
recommend component(s)

<>
return to Room

<>
purchase ProductComponent

<>
purchase ProductComponent

<>
request alternative

<>
purchase ProductComponent

<>
show description

Figure 13.5 Creating an NSU

282 PART TWO MODELING

You can create an NSU for each use case associated with each user role. For
example, a new customer for SafeHomeAssured.com may have three different use
cases, all resulting in access to different information and WebApp functions. An NSU
is created for each goal.

During the initial stages of navigation design, the WebApp content architecture is
assessed to determine one or more WoN for each use case. As noted earlier, a WoN
identifies navigation nodes (e.g., content) and then links that enable navigation between
them. The WoN are then organized into NSUs.

As design proceeds, your next task is to define the mechanics of navigation. Most
websites make use of one or more of the following navigation options for implement-
ing each NSU: individual navigation links, horizontal or vertical navigation bars
(lists), tabs, or access to a complete site map. If a site map is defined, it should be
accessible from every page. The map itself should be organized so that the structure
of WebApp information is readily apparent.

In addition to choosing the mechanics of navigation, you should also establish
appropriate navigation conventions and aids. For example, icons and graphical links
should look “clickable” by beveling the edges to give the image a three-dimensional
look. Audio or visual feedback should be designed to provide the user with an indica-
tion that a navigation option has been chosen. For text-based navigation, color should
be used to indicate navigation links and to provide an indication of links already
traveled. These are but a few of dozens of design conventions that make navigation
user-friendly.

13.6 co M p o n e n t-Le v e L De s i g n

Mobile apps deliver increasingly sophisticated processing functions that (1) perform
localized processing to generate content and navigation capability in a dynamic fash-
ion, (2) provide computation or data processing capability that are appropriate for the
app’s business domain, (3) provide sophisticated database query and access, and
(4) establish data interfaces with external corporate systems. To achieve these (and
many other) capabilities, you must design and construct program components that are
identical in form to software components for traditional software.

The design methods discussed in Chapters 11 and 12 apply to mobile components
with little, if any, modification. The implementation environment, programming lan-
guages, and design patterns, frameworks, and software may vary somewhat, but the
overall design approach remains the same. To be cost conscious, you can design
mobile components in such a way that they can be used without modification on
several different mobile platforms.

13.7 Mo b i L i t y a n D De s i g n Qua L i t y

Every person has an opinion about what makes a “good” mobile app. Individual
viewpoints vary widely. Some users enjoy flashy graphics; others want simple text.
Some demand copious information; others desire an abbreviated presentation. Some
like sophisticated analytical tools or database access; others like to keep it simple.

CHAPTER 13 DESIGN FOR MOBILITY 283

In fact, the user’s perception of “goodness” (and the resultant acceptance or rejection
of a mobile app as a consequence) might be more important than any technical dis-
cussion of mobile app quality. Mobile design quality attributes are virtually the same
as WebApp quality characteristics.

But how is mobile quality perceived? What attributes must be exhibited to achieve
goodness in the eyes of end users and at the same time exhibit the technical charac-
teristics of quality that will enable you to correct, adapt, enhance, and support the
mobile product over the long term?

In reality, all the technical characteristics of design quality discussed in Chapter 12
and the generic quality attributes presented in Chapter 19 apply to mobile apps. How-
ever, the most relevant of these generic attributes—usability, functionality, reliability,
efficiency, and maintainability—provide a useful basis for assessing the quality of
mobile systems as well. Andreou [And05] suggests that end-user satisfaction with a
mobile app is dictated by the same important quality factors—functionality, reliability,
usability, efficiency, and maintainability—but adds portability to the list.

Olsina and his colleagues [Ols99] have prepared a “quality requirement tree” that
identifies a set of technical attributes—usability, functionality, reliability, efficiency,
and maintainability—that lead to high-quality mobile products.25 Figure 13.6 sum-
marizes their work. The criteria noted in the figure are of particular interest if you
design, build, and maintain mobile products over the long term.

Web
application

quality

Usability

Functionality

Reliability

Maintainability

Efficiency

Online feedback and help features
Interface and aesthetic features

Global site understandability

Special features

Searching and retrieving capability
Navigation and browsing features
Application domain-related features

Correct link processing
Error recovery
User input validation and recovery

Response time performance
Page generation speed
Graphics generation speed

Response time performance
Page generation speed
Graphics generation speed

Figure 13.6
Quality
requirements
tree
Source: Olsina,
Luis, Lafuente,
Guillermo and
Rossi, Gustavo,
“Specifying Qual-
ity Characteristics
and Attributes
for Web Sites,”
Proceedings of
the 1st Interna-
tional Conference
on Software Engi-
neering Workshop
on Web Engineer-
ing, ACM,
Los Angeles,
May 1999.

25 These quality attributes are quite similar to those presented in Chapters 9 and 15. The
implication is that quality characteristics are universal for all software.

284 PART TWO MODELING

Offutt [Off02] extends the five major quality attributes noted in Figure 13.6 by
adding the following attributes:

Security. Mobile products have become heavily integrated with critical cor-
porate and government databases. E-commerce applications extract and then
store sensitive customer information. For these and many other reasons,
mobile security is paramount in many situations. The key measure of security
is the ability of the mobile app and its server environment to rebuff unauthor-
ized access and/or thwart an outright malevolent attack. Security engineering
is discussed in Chapter 18. For additional information on WebApp and mobile
app security, see [Web13], [Pri10], [Vac06], and [Kiz05].
Availability. Even the best mobile product will not meet users’ needs if it
is unavailable. In a technical sense, availability is the measure of the per-
centage of time that a Web-based mobile resource is available for use. But
Offutt [Off02] suggests that “using features available on only one browser
or one platform” makes the mobile product unavailable to those with a
different browser or platform configuration. The user will invariably go
elsewhere.
Scalability. Can the mobile product and its server environment be scaled to
handle 100, 1,000, 10,000, or 100,000 users? Will the app and the systems
with which it is interfaced handle significant variation in volume, or will
responsiveness drop dramatically (or cease altogether)? It is important to
design a mobile environment that can accommodate the burden of success
(i.e., significantly more end users) and become even more successful.
Time to Market. Although time to market is not a true quality attribute in
the technical sense, it is a measure of quality from a business point of view.
The first mobile product to address a specific market segment often captures
a disproportionate number of end users.
Content Quality. Billions of Web pages are available for those in search of
information. Even well-targeted Web searches result in an avalanche of con-
tent. With so many sources of information to choose from, how does the user
assess the quality (e.g., veracity, accuracy, completeness, timeliness) of the
content that is presented within a mobile product? This is part of what data
science tries to address. The basics of data science are introduced in
Appendix 2 of this book.

Tillman [Til00] suggests a useful set of criteria for assessing the quality of content:
Can the scope and depth of content be easily determined to ensure that it meets the
user’s needs? Can the background and authority of the content’s authors be easily
identified? Is it possible to determine the currency of the content, the last update, and
what was updated? Are the content and its location stable (i.e., will they remain at
the referenced URL)? Is content credible? Is content unique? That is, does the mobile
product provide some unique benefit to those who use it? Is content valuable to the
targeted user community? Is content well organized? Indexed? Easily accessible?
These questions represent only a small sampling of the issues that should be addressed
as the design of a mobile product evolves.

CHAPTER 13 DESIGN FOR MOBILITY 285

13.8 Mo b i L i t y De s i g n be st pr ac t i c e s

There are several guidelines for developing mobile products26 and for developing apps
for specific platforms like Apple’s iOS27 or Google’s Android.28 Schumacher [Sch09]
has collected many best practice ideas and has posted several specially adapted to the
design of mobile applications and Web pages. Some important considerations when
designing mobile touch-screen applications listed by Schumacher include:

∙ Identify your audience. The application must be written with the expecta-
tions and backgrounds of its users in mind. Experienced users want to do
things quickly. Less experienced users will appreciate a handholding approach
when they are first using the app.

∙ Design for context of use. It is important to consider how the user will inter-
act with the real world while using the mobile product. Watching a movie on
an airplane calls for a different user interface than checking the weather
before you leave the office.

∙ There is a fine line between simplicity and laziness. Creating an intuitive
user interface on a mobile device is much harder than simply removing
features found in the user interface for the application running on a larger
device. The user interface should provide all the information that enables
a user to make her next decision.

Mobile Product—Quality
Checklist
The following checklist provides a set of

questions that will help both software engineers and
end users assess overall mobile product quality:

∙ Can content, function, and/or navigation op­
tions be tailored to the user’s preferences?

∙ Can content and/or functionality be customized
to the bandwidth at which the user communi­
cates? Does the app account for weak or lost
signals in an acceptable manner?

∙ Can content, function, and/or navigation
options be made context aware according to
the user’s preferences?

∙ Has adequate consideration been given to the
power availability on the target device(s)?

∙ Have graphics, media (audio, video), and
other Web or cloud services been used
appropriately?

∙ Is the overall page design easy to read and
navigate? Does the app take screen­size
differences into account?

∙ Does the user interface conform to the display
and interaction standards adopted for the
targeted mobile device(s)?

∙ Does the app conform to the reliability,
security, and privacy expectations of its
users?

∙ What provisions have been made to ensure an
app remains current?

∙ Has the mobile product been tested in all
targeted user environments and for all targeted
devices?

info

26 See http://www.w3.org/TR/mwabp/.
27 See https://developer.apple.com/design/human-interface-guidelines/.
28 See http://developer.android.com/guide/components/index.html.

286 PART TWO MODELING

∙ Use the platform as an advantage. Touch-screen navigation is not intuitive
and must be learned by all new users. This learning task will be easier if
the user interface designers adhere to standards that have been set for the
platform.

∙ Make scrollbars and selection highlighting more salient. Scrollbars are
often hard to locate on touch devices because they are too small. Make sure
that menu or icon borders are wide enough for color changes to catch the
users’ attention. When color coding is used, make sure there is sufficient
contrast between foreground and background colors to allow them to be
distinguishable by any color-blind users.

∙ Increase discoverability of advanced functionality. Hot keys and other
shortcuts are sometimes included in mobile products to allow experienced
users to complete their tasks more quickly. You can increase the discoverabil-
ity of features like these by including visual design clues in the user interface.

∙ Use clear and consistent labels. Widget labels should be recognized by all
app users, regardless of standards used by specific platforms. Use abbrevia-
tions cautiously and avoid them if possible.

∙ Clever icons should never be developed at the expense of user under-
standing. Icons often only make sense to their designers. Users must be able
to learn their meaning quickly. It is hard to guarantee that icons are meaning-
ful across all languages and user groups. A good strategy to enhance recogni-
tion is to add a text label beneath a novel icon.

∙ Support user expectations for personalization. Mobile device users expect to
be able to personalize everything. At the very least, developers should try to
allow users to set their location (or detect it automatically) and select content
options that may be available at that location. It is important to indicate to
users what features can be personalized and how users can personalize them.

∙ Long scrolling forms trump multiple screens on mobile devices. Experi-
enced mobile device users want all information on a single input screen even
if this requires scrolling. Novice users often become experienced quickly and
will grow tired of multiple input screens.

Developing native applications for multiple device platforms can be costly and time
consuming. Development costs can be reduced by using technologies familiar to Web
developers (e.g., JavaScript, CSS, and HTML) to create mobile products that will be
accessed using a Web browser on a mobile device.

There are no guarantees that a desktop program or a WebApp can be easily adapted
for implementation as a mobile product. However, many of the agile software engineer-
ing practices (Chapter 3) used to create desktop computer applications can be used to
create stand-alone apps or mobile client software, and many of the practices used to
create quality WebApps apply to the creation of Web services used by mobile products.

The most important architectural design decision is often whether to build a thin
or fat client. The model-view-controller (MVC) architecture (Section 13.3) is com-
monly used in mobile products. Because the mobile architecture has a strong influence
on navigation, the decisions made during this design action will influence work con-
ducted during navigation design. The architectural design must take device resources

CHAPTER 13 DESIGN FOR MOBILITY 287

into account (storage, processor speed, and network connectivity). The design should
include provisions for discoverable services and movable devices.

Usability testing and deployment testing take place during each prototype develop-
ment cycle. Code reviews that focus on security issues should be included as part of
the implementation activities. These code reviews should be based on the appropriate
security objectives and threats identified in the system design activities. Security test-
ing is a routine part of system testing (Chapter 21).

13.9 su M M a ry

The quality of a mobile product—defined in terms of functionality, reliability, usabil-
ity, efficiency, security, maintainability, scalability, and portability—is introduced dur-
ing design. A good mobile product should be based on the following design goals:
simplicity, ubiquity, personalization, flexibility, and localization.

Interface design describes the structure and organization of the user interface and
includes a representation of screen layout, a definition of the modes of interaction,
and a description of navigation mechanisms. In addition, the interface for a good
mobile product will promote the brand signature and focus on its targeted device
platform(s). A set of core user stories is used to trim unnecessary features from the
app to manage its resource requirements. Context-aware devices make use of discov-
erable services to help personalize the user experience.

Content design is critically important and takes the screen and other limitations of
mobile devices into account. Aesthetic design, also called graphic design, describes
the “look and feel” of the mobile product and includes color schemes, graphic layout,
the use of graphics, and related aesthetic decisions. Aesthetic design must also take
device limitations into account.

Architecture design identifies the overall hypermedia structure for the mobile prod-
uct and encompasses both content architecture and mobile architecture. It is critical
to determine how much of the mobile functionality will reside on the mobile device
and how much will be provided by Web or cloud services.

Navigation design represents the navigational flow between content objects and for
all mobile functions. Navigation syntax is defined by the widgets available on the
targeted mobile device(s), and the semantics are often determined by the mobile plat-
form. Content chunking must take intermittent service interruptions and user demands
for fast performance into account.

Component design develops the detailed processing logic required to implement the
components that are used to build a complete MobileApp function. The design techniques
described in Chapter 12 may be applicable for the engineering of mobile components.

pro b L e M s a n D po i n t s to po n D e r

13.1. Explain why deciding to develop a MobileApp for several devices can be a costly design
decision. Is there a way to mitigate the risks of supporting the wrong platform?

13.2. In this chapter we listed many quality attributes for mobile products. Select the three that
you believe are most important, and make an argument that explains why each should be
emphasized in mobile design work.

288 PART TWO MODELING

13.3. You are a MobileApp designer for Project Planning Corporation, a company that builds
productivity software. You want to implement the equivalent of a digital three-ring binder that
allows tablet users to organize and categorize electronic documents of several types under user-
defined tabs. For example, a kitchen remodeling project might require a pdf catalog, a jpg or
layout drawing, an MS Word proposal, and an Excel spreadsheet stored under a Cabinetry tab.
Once defined, the binder and its tab content can be stored either on the tablet or on some cloud
storage. The application needs to provide five key functions: binder and tab definition, digital
document acquisition from a Web location or the device, binder management functions, page
display functions, and a notes function to allow a Post-it note to be added to any page. Develop
an interface design for the three-ring application, and implement it as a paper prototype.

13.4. What is the most aesthetically pleasing MobileApp you have ever used and why?

13.5. Create user stories for the three-ring application described in Problem 13.3.

13.6. What might be considered to make the three-ring application a context-aware MobileApp?

13.7. Reconsidering the ProjectPlanning three-ring application described in Problem 13.3,
select a development platform for the first working prototype. Discuss why you made the choice.

13.8. Do a bit of additional research on the MVC architecture and decide whether it would be
an appropriate MobileApp architecture for the three-ring discussed in Problem 13.3.

13.9. Describe three context-aware features that would be desirable to add to a SafeHome
MobileApp.

13.10. You are a WebApp designer for FutureLearning Corporation, a distance learning com-
pany. You intend to implement an Internet-based “learning engine” that will enable you to
deliver course content to a student. The learning engine provides the basic infrastructure for
delivering learning content on any subject (content designers will prepare appropriate content).
Develop a prototype interface design for the learning engine.

Design element: Quick Look icon magnifying glass: © Roger Pressman

181

C H A P T E R

10

What is it? Architectural design represents the struc-
ture of data and program components that are
required to build a computer-based system. It con-
siders the architectural style that the system will
take, the structure and properties of the compo-
nents that constitute the system, and the interrela-
tionships that occur among all architectural
components of a system.

Who does it? Although a software engineer can de-
sign both data and architecture, the job is often
allocated to specialists when large, complex sys-
tems are to be built. A database or data ware-
house designer creates the data architecture for a
system. The “system architect” selects an appro-
priate architectural style from the requirements
derived during software requirements analysis.

Why is it important? You wouldn’t attempt to build
a house without a blueprint, would you? You also
wouldn’t begin drawing blueprints by sketching
the plumbing layout for the house. You’d need to
look at the big picture—the house itself—before
you worry about details. That’s what architectural

design does—it provides you with the big picture
and ensures that you’ve got it right.

What are the steps? Architectural design begins
with data design and then proceeds to the deri-
vation of one or more representations of the ar-
chitectural structure of the system. Alternative
architectural styles or patterns are analyzed to
derive the structure that is best suited to cus-
tomer requirements and quality attributes. Once
an alternative has been selected, the architec-
ture is elaborated, using an architectural design
method.

What is the work product? An architecture model
encompassing data architecture and program
structure is created during architectural design.
In addition, component properties and relation-
ships (interactions) are described.

How do I ensure that I’ve done it right? At each
stage, software design work products are re-
viewed for clarity, correctness, completeness,
and consistency with requirements and with one
another.

Q u i c k L o o k

Design has been described as a multistep process in which representations of
data and program structure, interface characteristics, and procedural detail are
synthesized from

info

rmation requirements. As we noted in Chapter 9, design is
information driven. Software design methods are derived from consideration of
each of the three domains of the analysis model. The decisions made while
considering the data, functional, and behavioral domains serve as guides for the
creation of the software architectural design.

Architectural Design—A
Recommended Approach

agility and architecture . . . . . . . . . . . . . . . . . . 185
archetypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
architectural considerations . . . . . . . . . . . . . . 193
architectural decisions . . . . . . . . . . . . . . . . . . 195
architectural description language . . . . . . . . 184
architectural descriptions . . . . . . . . . . . . . . . . 184
architectural design . . . . . . . . . . . . . . . . . . . . 196
architectural patterns . . . . . . . . . . . . . . . . . . . 187

architectural styles . . . . . . . . . . . . . . . . . . . . . 186
architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
architecture conformance checking . . . . . . .204
architecture trade-off analysis
method (ATAM) . . . . . . . . . . . . . . . . . . . . . . . . 201
layered architectures . . . . . . . . . . . . . . . . . . . 189
refining the architecture . . . . . . . . . . . . . . . . . 198
taxonomy of architectural styles . . . . . . . . . . 187

k e y
c o n c e p t s

182 PART TWO MODELING

Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman [Mic09] suggest
that software architecture identifies a system’s “structural elements and their
interfaces,” along with the “behavior” of individual components and subsystems. They
write that the job of architectural design is to create “coherent, well-planned repre-
sentations” of the system and software.

Methods to create such representations of the data and architectural layers of the
design model are presented in this chapter. The objective is to provide a systematic
approach for the derivation of the architectural design—the preliminary blueprint from
which software is constructed.

10.1 so f t wa r e arc h i t e c t u r e

In their landmark book on the subject, Shaw and Garlan [Sha15] argue that since the
earliest days of computer programming, “software systems have had architectures, and
programmers have been responsible for the interactions among the modules and the
global properties of the assemblage.” Today, effective software architecture and its
explicit representation and design have become dominant themes in software engineering.

10.1.1 What Is Architecture?
When you consider the architecture of a building, many different attributes come to
mind. At the most simplistic level, you think about the overall shape of the physical
structure. But in reality, architecture is much more. It is the manner in which the
various components of the building are integrated to form a cohesive whole. It is the
way in which the building fits into its environment and meshes with other buildings
in its vicinity. It is the degree to which the building meets its stated purpose and
satisfies the needs of its owner. It is the aesthetic feel of the structure—the visual
impact of the building—and the way textures, colors, and materials are combined to
create the external facade and the internal “living environment.” It is small details—
the design of lighting fixtures, the type of flooring, the placement of wall hangings;
the list is almost endless. And finally, it is art.

Architecture is also something else. It is “thousands of decisions, both big and
small” [Tyr05]. Some of these decisions are made early in design and can have a
profound impact on all other design actions. Others are delayed until later, thereby
eliminating overly restrictive constraints that would lead to a poor implementation of
the architectural style.

Just like the plans for a house are merely a representation of the building, the
software architecture representation is not an operational product. Rather, it is a rep-
resentation that enables you to (1) analyze the effectiveness of the design in meeting
its stated requirements, (2) consider architectural alternatives at a stage when making
design changes is still relatively easy, and (3) reduce the risks associated with the
construction of the software.

This definition emphasizes the role of “software components” in any architectural
representation. In the context of architectural design, a software component can be
something as simple as a program module or an object-oriented class, but it can also
be extended to include databases and “middleware” that enable the configuration of

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 183

a network of clients and servers. The properties of components are those characteris-
tics that are necessary to an understanding of how the components interact with other
components. At the architectural level, internal properties (e.g., details of an algo-
rithm) are not specified. The relationships between components can be as simple as
a procedure call from one module to another or as complex as a database access
protocol.

We believe that a software design can be thought of as an instance of some software
architecture. However, the elements and structures that are defined as parts of par-
ticular software architectures are the root of every design. It is our recommendation
that design should begin with a consideration of the software architecture.

10.1.2 Why Is Architecture Important?
In a book dedicated to software architecture, Bass and his colleagues [Bas12] identify
three key reasons that software architecture is important:

∙ Software architecture provides a representation that facilitates communication
among all stakeholders.

∙ The architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows.

∙ The architecture constitutes a relatively small model of how the system com-
ponents are structured and work together.

The architectural design model and the architectural patterns contained within it
are transferable. That is, architecture genres, styles, and patterns (Sections 10.3 through
10.6) can be applied to the design of other systems and represent a set of abstractions
that enable software engineers to describe architecture in predictable ways.

Making good decisions while defining the software architecture is critical to the
success of a software product. The software architecture sets the structure of the
system and determines its quality [Das15].

10.1.3 Architectural Descriptions
Each of us has a mental image of what the word architecture means. The implication
is that different stakeholders will see a given software architecture from different
viewpoints that are driven by different sets of concerns. This implies that an archi-
tectural description is actually a set of work products that reflect different views of
the system.

Smolander, Rossi, and Purao [Smo08] have identified multiple metaphors, repre-
senting different views of the same architecture that stakeholders use to understand
the term software architecture. The blueprint metaphor seems to be most familiar to
the stakeholders who write programs to implement a system. Developers regard archi-
tecture descriptions as a means of transferring explicit information from architects to
designers to software engineers charged with producing the system components.

The language metaphor views architecture as a facilitator of communication across
stakeholder groups. This view is preferred by stakeholders with a high customer focus
(e.g., managers or marketing experts). The architectural description needs to be con-
cise and easy to understand because it forms the basis for negotiation, particularly in
determining system boundaries.

184 PART TWO MODELING

The decision metaphor represents architecture as the product of decisions involving
trade-offs among properties such as cost, usability, maintainability, and performance
that have resource consequences for the system being designed. Stakeholders such as
project managers view architectural decisions as the basis for allocating project
resources and tasks. These decisions may affect the sequence of tasks and shape the
structure of the software team.

The literature metaphor is used to document architectural solutions constructed in
the past. This view supports the construction of artifacts and the transfer of knowledge
between designers and software maintenance staff. It also supports stakeholders whose
concern is reuse of components and designs.

An architectural description (AD) represents a system using multiple views, where
each view is “a representation of a whole system from the perspective of a related set
of [stakeholder] concerns.” The IEEE Computer Society standard IEEE-Std-
42010:2011(E), Systems and software engineering—Architectural description [IEE11],
describes the use of architecture viewpoints, architecture frameworks, and architecture
description languages as a means of codifying the conventions and common practices
for architectural description.

10.1.4 Architectural Decisions
Each view developed as part of an architectural description addresses a specific stake-
holder concern. To develop each view (and the architectural description as a whole),
the system architect considers a variety of alternatives and ultimately decides on the
specific architectural features that best meet the concern. Architectural decisions them-
selves can be considered to be one view of the architecture. The reasons that decisions
were made provide insight into the structure of a system and its conformance to
stakeholder concerns.

As a system architect, you can use the template suggested in the sidebar to docu-
ment each major decision. By doing this, you provide a rationale for your work and
establish a historical record that can be useful when design modifications must be
made. For agile developers, a lightweight architectural decision record (ADR) might
simply contain a title, a context (assumptions and constraints), the decision (resolu-
tion), status (proposed accepted rejected), and consequences (implications) [Nyg11].

Grady Booch [Boo11a] writes that when setting out to build an innovative prod-
uct, software engineers often feel compelled to plunge right in, build stuff, fix what
doesn’t work, improve what does work, and then repeat the process. After doing
this a few times, they begin to recognize that the architecture should be defined first
and decisions associated with architectural choices must be stated explicitly. It may
not be possible to predict the right choices before building a new product. However,
if innovators find that architectural decisions are worth repeating after testing their
prototypes in the field, then a dominant design1 for this type of product may begin
to emerge. Without documenting what worked and what did not, it is hard for soft-
ware engineers to decide when to innovate and when to use previously created
architecture.

1 Dominant design describes an innovative software architecture or process that becomes an
industry standard after a period of successful adaptation and use in the marketplace.

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 185

10.2 ag i L i t y a n d arc h i t e c t u r e

The view of some agile developers is that architectural design is equated with “big
design upfront.” In their view, this leads to unnecessary documentation and the imple-
mentation of unnecessary features. However, most agile developers would agree
[Fal10] that it is important to focus on software architecture when a system is complex
(i.e., when a product has a large number of requirements, lots of stakeholders, or a
large number of global users). For this reason, it is important to integrate new archi-
tectural design practices into agile process models.

To make early architectural decisions and avoid the rework required to correct the
quality problems encountered when the wrong architecture is chosen, agile developers

Architecture Decision
Description Template
Each major architectural decision can

be documented for later review by stakeholders
who want to understand the architecture descrip-
tion that has been proposed. The template
presented in this sidebar is an adapted and
abbreviated version of a template proposed
by Tyree and Ackerman [Tyr05].

Design issue: Describe the architectural
design issues that are to be
addressed.

Resolution: State the approach you’ve
chosen to address the
design issue.

Category: Specify the design category
that the issue and resolution
address (e.g., data design,
content structure, compo-
nent structure, integration,
presentation).

Assumptions: Indicate any assumptions
that helped shape the
decision.

Constraints: Specify any environmental
constraints that helped
shape the decision (e.g.,
technology standards,
available patterns, project-
related issues).

Alternatives: Briefly describe the architec-
tural design alternatives that
were considered and why
they were rejected.

Argument: State why you chose the
resolution over other
alternatives.

Implications: Indicate the design
consequences of making
the decision. How will the
resolution affect other
architectural design issues?
Will the resolution constrain
the design in any way?

Related decisions: What other documented
decisions are related to
this decision?

Related concerns: What other requirements
are related to this
decision?

Work products: Indicate where this
decision will be reflected
in the architecture
description.

Notes: Reference any team notes
or other documentation that
was used to make the
decision.

info

186 PART TWO MODELING

need to anticipate architectural elements2 and implied structure that emerges from the
collection of user stories gathered (Chapter 7). By creating an architectural prototype
(e.g., a walking skeleton) and developing explicit architectural work products to com-
municate the right information to the necessary stakeholders, an agile team can satisfy
the need for architectural design.

Using a technique called storyboarding, the architect contributes architectural user
stories to the project and works with the product owner to prioritize the architectural
stories with the business user stories as “sprints” (work units) are planned. The archi-
tect works with the team during the sprint to ensure that the evolving software con-
tinues to show high architectural quality as defined by the nonfunctional product
requirements. If quality is high, the team is left alone to continue development on its
own. If not, the architect joins the team for the duration of the sprint. After the sprint
is completed, the architect reviews the working prototype for quality before the team
presents it to the stakeholders in a formal sprint review. Well-run agile projects make
use of iterative work product delivery (including architectural documentation) with
each sprint. Reviewing the work products and code as it emerges from each sprint is
a useful form of architectural review.

Responsibility-driven architecture (RDA) is a process that focuses on when, how,
and who should make the architectural decisions on a project team. This approach
also emphasizes the role of architect as being a servant-leader rather than an autocratic
decision maker and is consistent with the agile philosophy. The architect acts as
facilitator and focuses on how the development team works to accommodate stake-
holder’s nontechnical concerns (e.g., business, security, usability).

Agile teams usually have the freedom to make system changes as new requirements
emerge. Architects want to make sure that the important parts of the architecture were
carefully considered and that developers have consulted the appropriate stakeholders.
Both concerns may be satisfied by making use of a practice called progressive sign-off
in which the evolving product is documented and approved as each successive proto-
type is completed [Bla10].

Using a process that is compatible with the agile philosophy provides verifiable
sign-off for regulators and auditors, without preventing the empowered agile teams
from making the decisions needed. At the end of the project, the team has a com-
plete set of work products and the architecture has been reviewed for quality as
it  evolved.

10.3 arc h i t e c t u r a L st y L e s

When a builder uses the phrase “center hall colonial” to describe a house, most
people familiar with houses in the United States will be able to conjure a general
image of what the house will look like and what the floor plan is likely to be. The
builder has used an architectural style as a descriptive mechanism to differentiate the
house from other styles (e.g., A-frame, raised ranch, Cape Cod). But more important,

2 An excellent discussion of architectural agility can be found in [Bro10a].

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 187

the architectural style is also a template for construction. Further details of the house
must be defined, its final dimensions must be specified, customized features may
be added, building materials are to be determined, but the style—a “center hall
colonial”—guides the builder in his work.

The software that is built for computer-based systems also exhibits one of many
architectural styles. Each style describes a system category that encompasses (1) a set
of components (e.g., a database, computational modules) that perform a function
required by a system, (2) a set of connectors that enable “communication, coordination
and cooperation” among components, (3) constraints that define how components can
be integrated to form the system, and (4) semantic models that enable a designer to
understand the overall properties of a system by analyzing the known properties of
its constituent parts [Bas12].

An architectural style is a transformation that is imposed on the design of an entire
system. The intent is to establish a structure for all components of the system. In the
case where an existing architecture is to be refactored (Chapter 27), the imposition of
an architectural style will result in fundamental changes to the structure of the software
including a reassignment of the functionality of components [Bos00].

An architectural pattern, like an architectural style, imposes a transformation on
the design of an architecture. However, a pattern differs from a style in a number of
fundamental ways: (1) the scope of a pattern is less broad, focusing on one aspect of
the architecture rather than the architecture in its entirety, (2) a pattern imposes a rule
on the architecture, describing how the software will handle some aspect of its func-
tionality at the infrastructure level (e.g., concurrency) [Bos00], and (3) architectural
patterns (Section 10.3.2) tend to address specific behavioral issues within the context
of the architecture (e.g., how real-time applications handle synchronization or inter-
rupts). Patterns can be used in conjunction with an architectural style to shape the
overall structure of a system.

10.3.1 A Brief Taxonomy of Architectural Styles
Although millions of computer-based systems have been created over the past
60  years, the vast majority can be categorized into one of a relatively small
number of architectural styles.

Data-Centered Architectures. A data store (e.g., a file or database) resides at the
center of this architecture and is accessed frequently by other components that update,
add, delete, or otherwise modify data within the store. Figure 10.1 illustrates a typical
data-centered style. Client software accesses a central repository. In some cases, the
data repository is passive. That is, client software accesses the data independent of
any changes to the data or the actions of other client software. A variation on this
approach transforms the repository into a “blackboard” that sends notifications to
client software when data of interest to the client changes.

Data-centered architectures promote integrability [Bas12]. That is, existing compo-
nents can be changed and new client components added to the architecture without
concern about other clients (because the client components operate independently). In
addition, data can be passed among clients using the blackboard mechanism (i.e., the
blackboard component serves to coordinate the transfer of information between
clients). Client components independently execute processes.

188 PART TWO MODELING

Data-Flow Architectures. This architecture is applied when input data are to be
transformed through a series of computational or manipulative components into output
data. A pipe-and-filter pattern (Figure 10.2) has a set of components, called filters,
connected by pipes that transmit data from one component to the next. Each filter
works independently of those components upstream and downstream, is designed to
expect data input of a certain form, and produces data output (to the next filter) of a
specified form. However, the filter does not require knowledge of the workings of its
neighboring filters.

Client

Software

Client
Software

Client
Software

Client
Software

Client
Software

Client
Software

Client
Software

Client
Software

Data store
(repository or blackboard)

Figure 10.1
Data-centered
architecture

Filter

Filter

Filter

Filter

Filter

Filter

Filter

Filter

Filter

Filter

Pipes

Figure 10.2 Data-flow architecture

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 189

Call-and-Return Architectures. This architectural style enables you to achieve a
program structure that is relatively easy to modify and scale. Two substyles [Bas12]
that exist within this category:

∙ Main program/subprogram architectures. This classic program structure
decomposes function into a control hierarchy where a “main” program
invokes several program components, which in turn may invoke still other
components. Figure 10.3 illustrates an architecture of this type.

∙ Remote procedure call architectures. The components of a main program/
subprogram architecture are distributed across multiple computers on a
network.

Object-Oriented Architectures. The components of a system encapsulate data
and the operations that must be applied to manipulate the data. Communication
and coordination between components are accomplished via message passing. Fig-
ure 10.4 contains a UML communication diagram that shows the message passing
for the login portion of a system implemented using an object-oriented architec-
ture. Communications diagrams are described in more details in Appendix 1 of
this book.

Layered Architectures. The basic structure of a layered architecture is illustrated
in Figure 10.5. A number of different layers are defined, each accomplishing opera-
tions that progressively become closer to the machine instruction set. At the outer
layer, components service user interface operations. At the inner layer, components
perform operating system interfacing. Intermediate layers provide utility services and
application software functions.

Model-View-Controller (MVC) architecture [Kra88] is one of a number of sug-
gested mobile infrastructure models often used in Web development. The model con-
tains all application-specific content and processing logic. The view contains all

Application
subprogram

Application
subprogram

Main
program

Controller

subprogram

Application
subprogram

Application
subprogram

Controller
subprogram

Application
subprogram

Application
subprogram

Application
subprogram

Controller
subprogram

Figure 10.3 Main program/subprogram architecture

190 PART TWO MODELING

Core layer

Utility layer

Application layer

User interface layer
Components

Figure 10.5
Layered
architecture

Actor

: SecurityLogon

: AccountDB

: System

1 : requestLogon()
2: Logon(name,pass)

3: isValid():boolean

4: userType(name):string

1.2: displayLogon()
3.1 : displayMessage()
4.1 : display()

Figure 10.4
UML
communication
diagram

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 191

interface-specific functions and enables the presentation of content and processing
logic required by the end user. The controller manages access to the model and the
view and coordinates the flow of data between them. A schematic representation of
the MVC architecture is shown in Figure 10.6.

Referring to the figure, user requests are handled by the controller. The controller
also selects the view object that is applicable based on the user request. Once the type
of request is determined, a behavior request is transmitted to the model, which imple-
ments the functionality or retrieves the content required to accommodate the request.
The model object can access data stored in a corporate database, as part of a local
data store, or as a collection of independent files. The data developed by the model
must be formatted and organized by the appropriate view object and then transmitted
from the application server back to the client-based browser for display on the cus-
tomer’s machine.

These architectural styles are only a small subset of those available.3 Once require-
ments engineering uncovers the characteristics and constraints of the system to be
built, the architectural style and/or combination of patterns that best fits those char-
acteristics and constraints can be chosen. In many cases, more than one pattern might
be appropriate and alternative architectural styles can be designed and evaluated. For
example, a layered style (appropriate for most systems) can be combined with a data-
centered architecture in many database applications.

View
Prepares data from model
Requests updates from model
Presents view selected by controller

Controller
Manages user requests
Selects model behavior
Selects view response

Model
Encapsulates functionality
Encapsulates content objects
Incorporates all WebApp states

Server

Client

Browser

Update request
External data

Data from model

View selection
Behavior request

(state change)
User

request
or data

HTML data

Figure 10.6 The MVC architecture

Source: Adapted from Jacyntho, Mark Douglas, Schwabe, Daniel and Rossi, Gustavo, “An Architecture for Structuring
Complex Web Applications,” 2002, available at http://www-di.inf.puc-rio.br/schwabe/papers/OOHDMJava2%20Report

3 See [Roz11], [Tay09], [Bus07], [Gor06], or [Bas12] for a detailed discussion of architectural
styles and patterns.

192 PART TWO MODELING

Choosing the right architecture style can be tricky. Real-world problems often follow
more than one problem frame, and a combination architectural model may result. For
example, the model-view-controller (MVC) architecture used in WebApp design4 might
be viewed as combining two problem frames (command behavior and information dis-
play). In MVC, the end user’s command is sent from the browser window to a command
processor (controller) that manages access to the content (model) and instructs the infor-
mation rendering model (view) to translate it for display by the browser software.

10.3.2 Architectural Patterns
As the requirements model is developed, you’ll notice that the software must address
several broad problems that span the entire application. For example, the requirements
model for virtually every e-commerce application is faced with the following problem:
How do we offer a broad array of goods to many different customers and allow those
customers to find and purchase our goods easily?

The requirements model also defines a context in which this question must be
answered. For example, an e-commerce business that sells golf equipment to consum-
ers will operate in a different context than an e-commerce business that sells high-
priced industrial equipment to medium and large corporations. In addition, a set of
limitations and constraints may affect the way you address the problem to be solved.

Choosing an Architectural Style

The scene: Jamie’s cubicle, as
design modeling begins.

The players: Jamie and Ed—members of the
SafeHome software engineering team.

The conversation:
Ed (frowning): We’ve been modeling the
security function using UML . . . you know,
classes, relationships, that sort of stuff. So
I guess the object-oriented architecture is
the right way to go.

Jamie: But . . .?

Ed: But . . . I have trouble visualizing what an
object-oriented architecture is. I get the call-
and-return architecture, sort of a conventional
process hierarchy, but OO . . . I don’t know, it
seems sort of amorphous.

Jamie (smiling): Amorphous, huh?

Ed: Yeah . . . what I mean is I can’t visualize a real
structure, just design classes floating in space.

Jamie: Well, that’s not true. There are class
hierarchies . . . think of the hierarchy (aggre-
gation) we did for the FloorPlan object
[Figure 9.3]. An OO architecture is a combina-
tion of that structure and the interconnections—
you know, collaborations—between the
classes. We can show it by fully describing
the attributes and operations, the messaging
that goes on, and the structure of the
classes.

Ed: I’m going to spend an hour mapping out a
call-and-return architecture; then I’ll go back
and consider an OO architecture.

Jamie: Doug’ll have no problem with that.
He said that we should consider architectural
alternatives. By the way, there’s absolutely no
reason why both of these architectures
couldn’t be used in combination with one
another.

Ed: Good. I’m on it.

safehome

4 The MVC architecture is considered in more detail in Chapter 13.

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 193

Architectural patterns address an application-specific problem within a specific
context and under a set of limitations and constraints. The pattern proposes an archi-
tectural solution that can serve as the basis for architectural design.

Previously in this chapter, we noted that most applications fit within a specific domain
or genre and that one or more architectural styles may be appropriate for that genre. For
example, the overall architectural style for an application might be call and return or
object oriented. But within that style, you will encounter a set of common problems that
might best be addressed with specific architectural patterns. Some of these problems and
a more complete discussion of architectural patterns are presented in Chapter 14.

10.3.3 Organization and Refinement
Because the design process often leaves you with a number of architectural alterna-
tives, it is important to establish a set of design criteria that can be used to assess an
architectural design that is derived. The following questions [Bas12] provide insight
into an architectural style:

Control. How is control managed within the architecture? Does a distinct
control hierarchy exist, and if so, what is the role of components within this
control hierarchy? How do components transfer control within the system?
How is control shared among components? What is the control topology
(i.e.,  the geometric form that the control takes)? Is control synchronized,
or do components operate asynchronously?
Data. How are data communicated between components? Is the flow of data
continuous, or are data objects passed to the system sporadically? What is the
mode of data transfer (i.e., are data passed from one component to another or
are data available globally to be shared among system components)? Do data
components (e.g., a blackboard or repository) exist, and if so, what is their
role? How do functional components interact with data components? Are data
components passive or active (i.e., does the data component actively interact
with other components in the system)? How do data and control interact
within the system?

The answers to these questions provide the designer with an early assessment of
design quality and lay the foundation for more detailed analysis of the architecture.

Evolutionary process models (Chapter 2) have become very popular. This implies
the software architectures may need to evolve as each product increment is planned
and implemented. In Chapter 9, we described this process as refactoring—improving
the internal structure of the system without changing its external behavior.

10.4 arc h i t e c t u r a L co n s i d e r at i o n s

Buschmann and Henny [Bus10a, Bus10b] suggest several architectural considerations
that can provide software engineers with guidance as architecture decisions are made.

∙ Economy. The best software is uncluttered and relies on abstraction to reduce
unnecessary detail. It avoids complexity due to unnecessary functions and
features.

194 PART TWO MODELING

∙ Visibility. As the design model is created, architectural decisions and the
reasons for them should be obvious to software engineers who examine the
model later. Important design and domain concepts must be communicated
effectively.

∙ Spacing. Separation of concerns (Chapter 9) in a design is sometimes referred
to as spacing. Sufficient spacing leads to modular designs, but too much
spacing leads to fragmentation and loss of visibility.

∙ Symmetry. Architectural symmetry implies that a system is consistent and
balanced in its attributes. Symmetric designs are easier to understand, com-
prehend, and communicate. As an example of architectural symmetry, con-
sider a customer account object whose life cycle is modeled directly by a
software architecture that requires both open() and close() methods. Architec-
tural symmetry can be both structural and behavioral.

∙ Emergence. Emergent, self-organized behavior and control are often the key
to creating scalable, efficient, and economic software architectures. For exam-
ple, many real-time software applications are event driven. The sequence and
duration of these events that define the system’s behavior is an emergent
quality. Because it is very difficult to plan for every possible sequence of
events, a system architect should create a flexible system that accommodates
this emergent behavior.

These considerations do not exist in isolation. They interact with each other and are
moderated by each other. For example, spacing can be both reinforced and reduced
by economy. Visibility can be balanced by spacing.

The architectural description for a software product is not explicitly visible in the
source code used to implement it. As a consequence, code modifications made over
time (e.g., software maintenance activities) can cause slow erosion of the software
architecture. The challenge for a designer is to find suitable abstractions for the archi-
tectural information. These abstractions have the potential to add structuring that
improves readability and maintainability of the source code [Bro10b].

Evaluating Architectural Decisions

The scene: Jamie’s cubicle, as
design modeling continues.

The players: Jamie and Ed, members of the
SafeHome software engineering team.

The conversation:
Ed: I finished my call-return architectural
model of the security function.

Jamie: Great! Do you think it meets our
needs?

Ed: It doesn’t introduce any unneeded features,
so it seems to be economic.

Jamie: How about visibility?

Ed: Well, I understand the model, and there’s
no problem implementing the security require-
ments needed for this product.

Jamie: I get that you understand the architec-
ture, but you may not be the programmer for
this part of the project. I’m a little worried

safehome

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 195

10.5 arc h i t e c t u r a L de c i s i o n s

Decisions about system architecture identify key design issues and the rationale behind
chosen architectural solutions. System architecture decisions encompass software sys-
tem organization, selection of structural elements and their interfaces as defined by
their intended collaborations, and the composition of these elements into increasingly
larger subsystems [Kru09]. In addition, choices of architectural patterns, application
technologies, middleware assets, and programming language can also be made. The
outcome of the architectural decisions influences the system’s nonfunctional charac-
teristics and many of its quality attributes [Zim11] and can be documented with
developer notes. These notes document key design decisions along with their justifi-
cation, provide a reference for new project team members, and serve as a repository
for lessons learned.

In general, software architectural practice focuses on architectural views that rep-
resent and document the needs of various stakeholders. It is possible, however, to
define a decision view that cuts across several views of information contained in
traditional architectural representations. The decision view captures both the architec-
ture design decisions and their rationale.

Service-oriented architecture decision (SOAD)5 modeling [Zim11] is a knowledge
management framework that provides support for capturing architectural decision
dependencies in a manner that allows them to guide future development activities.

about spacing. This design may not be as
modular as an object-oriented design.

Ed: Maybe, but that may limit our ability to re-
use some of our code when we have to create
the mobile version of SafeHome.

Jamie: What about symmetry?

Ed: Well, that’s harder for me to assess. It
seems to me the only place for symmetry in
the security function is adding and deleting
PIN information.

Jamie: That will get more complicated when
we add remote security features to the
mobile app.

Ed: That’s true, I guess.

(They both pause for a moment, pondering the
architectural issues.)

Jamie: SafeHome is a real-time system, so
state transition and sequencing of events will
be tough to predict.

Ed: Yeah, but the emergent behavior of this
system can be handled with a finite state
model.

Jamie: How?

Ed: The model can be implemented based on
the call-return architecture. Interrupts can be
handled easily in many programming
languages.

Jamie: Do you think we need to do the same
kind of analysis for the object-oriented archi-
tecture we were initially considering?

Ed: I suppose it might be a good idea,
because architecture is hard to change once
implementation starts.

Jamie: It’s also important for us to map the
nonfunctional requirements besides security
on top of these architectures to be sure they
have been considered thoroughly.

Ed: Also, true.

5 SOAD is analogous to the use of architecture patterns discussed in Chapter 14.

196 PART TWO MODELING

A SOAD guidance model contains knowledge about architectural decisions required
when applying an architectural style in a particular application genre. It is based on
architectural information obtained from completed projects that employed the archi-
tectural style in that genre. The guidance model documents places where design prob-
lems exist and architectural decisions must be made, along with quality attributes that
should be considered in selecting from among potential alternatives. Potential alterna-
tive solutions (with their pros and cons) from previous software applications are
included to assist the architect in making the best decision possible.

A SOAD decision model documents both the architectural decisions required and
records the decisions actually made on previous projects with their justifications. The
guidance model feeds the architectural decision model in a tailoring step that allows
the architect to delete irrelevant issues, enhance important issues, or add new issues.
A decision model can make use of more than one guidance model and provides feed-
back to the guidance model after the project is completed. This feedback may be
accomplished by harvesting lessons learned from project postmortem reviews.

10.6 arc h i t e c t u r a L de s i g n

As architectural design begins, context must be established. To accomplish this, the
external entities (e.g., other systems, devices, people) that interact with the software
and the nature of their interaction are described. This information can generally be
acquired from the requirements model. Once context is modeled and all external soft-
ware interfaces have been described, you can identify a set of architectural archetypes.

An archetype is an abstraction (similar to a class) that represents one element of
system behavior. The set of archetypes provides a collection of abstractions that must
be modeled architecturally if the system is to be constructed, but the archetypes them-
selves do not provide enough implementation detail. Therefore, the designer specifies
the structure of the system by defining and refining software components that imple-
ment each archetype. This process continues iteratively until a complete architectural
structure has been derived.

Several questions [Boo11b] must be asked and answered as a software engineer
creates meaningful architectural diagrams. Does the diagram show how the system
responds to inputs or events? What visualizations might there be to help emphasize
areas of risk? How can hidden system design patterns be made more obvious to other
developers? Can multiple viewpoints show the best way to refactor specific parts of
the system? Can design trade-offs be represented in a meaningful way? If a diagram-
matic representation of software architecture answers these questions, it will have
value to software engineers that use it.

10.6.1 Representing the System in Context
UML does not contain specific diagrams that represent the system in context. Software
engineers wishing to stick with UML and represent the system in context would do
so with a combination of use case, class, component, activity, sequence, and collabo-
ration diagrams. Some software architects may make use of an architectural context
diagram (ACD) to model the manner in which software interacts with entities external
to its boundaries. An architectural context diagram for the SafeHome security func-
tions is shown in Figure 10.7.

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 197

To illustrate the use of the ACD, consider the home security function of the Safe-
Home product shown in Figure 10.7. The overall SafeHome product controller and the
Internet-based system are both superordinate to the security function and are shown
above the function. The surveillance function is a peer system and uses (is used by)
the home security function in later versions of the product. The homeowner and con-
trol panels are actors that produce and consume information that is, respectively, used
and produced by the security software. Finally, sensors are used by the security soft-
ware and are shown as subordinate to it (by drawing them below the target system).

As part of the architectural design, the details of each interface shown in Figure 10.7
would have to be specified. All data that flow into and out of the target system must
be identified at this stage.

10.6.2 Defining Archetypes
An archetype is a class or pattern that represents a core abstraction that is critical to
the design of an architecture for the target system. In general, a relatively small set
of archetypes is required to design even relatively complex systems. The target system
architecture is composed of these archetypes, which represent stable elements of the
architecture but may be instantiated many different ways based on the behavior of the
system.

In many cases, archetypes can be derived by examining the analysis classes defined
as part of the requirements model. Continuing the discussion of the SafeHome home
security function, you might define the following archetypes:

∙ Node. Represents a cohesive collection of input and output elements of
the home security function. For example, a node might be composed of
(1) various sensors and (2) a variety of alarm (output) indicators.

∙ Detector. An abstraction that encompasses all sensing equipment that feeds
information into the target system.

Uses

Uses

Uses

Peers

Figure 10.7
Architectural
context
diagram for
the SafeHome
security
function

198 PART TWO MODELING

∙ Indicator. An abstraction that represents all mechanisms (e.g., alarm siren,
flashing lights, bell) for indicating that an alarm condition is occurring.

∙ Controller. An abstraction that depicts the mechanism that allows the
arming or disarming of a node. If controllers reside on a network, they
have the ability to communicate with one another.

Each of these archetypes is depicted using UML notation, as shown in Figure 10.8.
Recall that the archetypes form the basis for the architecture but are abstractions that
must be further refined as architectural design proceeds. For example, Detector might
be refined into a class hierarchy of sensors.

10.6.3 Refining the Architecture into Components
As the software architecture is refined into components, the structure of the system
begins to emerge. But how are these components chosen? To answer this question,
you begin with the classes that were described as part of the requirements model.6
These analysis classes represent entities within the application (business) domain that
must be addressed within the software architecture. Hence, the application domain is
one source for the derivation and refinement of components. Another source is the
infrastructure domain. The architecture must accommodate many infrastructure com-
ponents that enable application components but have no business connection to the
application domain. For example, memory management components, communication
components, database components, and task management components are often inte-
grated into the software architecture.

Detector Indicator

Controller

Communicates with

Node

Figure 10.8
UML
relationships
for SafeHome
security
function
archetype
Source: Adapted
from Bosch, Jan,
Design & Use of
Software Architec-
tures. Pearson
Education, 2000.

6 If a conventional (non-object-oriented) approach is chosen, components may be derived from
the subprogram calling hierarchy (see Figure 10.3).

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 199

The interfaces depicted in the architecture context diagram (Section 10.6.1) imply
one or more specialized components that process the data that flows across the inter-
face. In some cases (e.g., a graphical user interface), a complete subsystem architec-
ture with many components must be designed.

Continuing the SafeHome home security function example, you might define the
set of top-level components that addresses the following functionality:

∙ External communication management. Coordinates communication of the
security function with external entities such as other Internet-based systems
and external alarm notification.

∙ Control panel processing. Manages all control panel functionality.
∙ Detector management. Coordinates access to all detectors attached to the

system.
∙ Alarm processing. Verifies and acts on all alarm conditions.

Each of these top-level components would have to be elaborated iteratively and
then positioned within the overall SafeHome architecture. Design classes (with appro-
priate attributes and operations) would be defined for each. It is important to note,
however, that the design details of all attributes and operations would not be specified
until component-level design (Chapter 11).

The overall architectural structure (represented as a UML component diagram) is
illustrated in Figure 10.9. Transactions are acquired by external communication man-
agement as they move in from components that process the SafeHome GUI and the
Internet interface. This information is managed by a SafeHome executive component
that selects the appropriate product function (in this case security). The control panel
processing component interacts with the homeowner to arm and disarm the security

SafeHome
Executive

GUI Internet
interface

Security Surveillance

Function
selection

Home

management

External
communication
management

Control
panel

processing

Detector
management

Alarm
processing

Figure 10.9 Overall architectural structure for SafeHome with top-level components

200 PART TWO MODELING

function. The detector management component polls sensors to detect an alarm condi-
tion, and the alarm processing component produces output when an alarm is detected.

10.6.4 Describing Instantiations of the System
The architectural design that has been modeled to this point is still relatively high
level. The context of the system has been represented, archetypes that indicate the
important abstractions within the problem domain have been defined, the overall struc-
ture of the system is apparent, and the major software components have been identi-
fied. However, further refinement (recall that all design is iterative) is still necessary.

To accomplish this, an actual instantiation of the architecture is developed. By this
we mean that the architecture is applied to a specific problem with the intent of
demonstrating that the structure and components are appropriate.

Figure 10.10 illustrates an instantiation of the SafeHome architecture for the secu-
rity system. Components shown in Figure 10.9 are elaborated to show additional
detail. For example, the detector management component interacts with a scheduler
infrastructure component that implements polling of each sensor object used by the
security system. Similar elaboration is performed for each of the components repre-
sented in Figure 10.10.

CP display
functions

Keypad
processing

Phone
communication Alarm

SafeHome
Executive

GUI Internet
interface

Security

External
communication
management

Control
panel

processing
Detector

management

Scheduler

Alarm
processing

Sensor

Figure 10.10 An instantiation of the security function with component elaboration

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 201

10.7 as s e s s i ng aLt e r nat i v e arc h i t e c t u r a L de s i g n s

In their book on the evaluation of software architectures, Clements and his colleagues
[Cle03] state, “To put it bluntly, an architecture is a bet, a wager on the success of a
system.”

The big question for a software architect and the software engineers who will work
to build a system is simple: Will the architectural bet pay off?

To help answer this question, architectural design should result in a number of
architectural alternatives that are each assessed to determine which is the most appro-
priate for the problem to be solved.

The Software Engineering Institute (SEI) has developed an architecture trade-off
analysis method (ATAM) [Kaz98] that establishes an iterative evaluation process for
software architectures. The design analysis activities that follow are performed
iteratively:

1. Collect scenarios. A set of use cases (Chapters 7 and 8) is developed to
represent the system from the user’s point of view.

2. Elicit requirements, constraints, and environment description. This infor-
mation is required as part of requirements engineering and is used to be
certain that all stakeholder concerns have been addressed.

3. Describe the architectural styles and patterns that have been chosen to
address the scenarios and requirements. The architectural style(s) should be
described using one of the following architectural views:
∙ Module view for analysis of work assignments with components and the

degree to which information hiding has been achieved.
∙ Process view for analysis of system performance.
∙ Data flow view for analysis of the degree to which the architecture meets

functional requirements.
4. Evaluate quality attributes by considering each attribute in isolation. The

number of quality attributes chosen for analysis is a function of the time
available for review and the degree to which quality attributes are relevant to
the system at hand. Quality attributes for architectural design assessment
include reliability, performance, security, maintainability, flexibility, testability,
portability, reusability, and interoperability.

5. Identify the sensitivity of quality attributes to various architectural attri-
butes for a specific architectural style. This can be accomplished by making
small changes in the architecture and determining how sensitive a quality
attribute, say performance, is to the change. Any attributes that are signifi-
cantly affected by variation in the architecture are termed sensitivity points.

6. Critique candidate architectures (developed in step 3) using the sensitivity
analysis conducted in step 5. The SEI describes this approach in the follow-
ing manner [Kaz98]:

Once the architectural sensitivity points have been determined, finding trade-off
points is simply the identification of architectural elements to which multiple attri-
butes are sensitive. For example, the performance of a client-server architecture might

202 PART TWO MODELING

be highly sensitive to the number of servers (performance increases, within some
range, by increasing the number of servers).  .  .  . The number of servers, then, is a
trade-off point with respect to this architecture.

These six steps represent the first ATAM iteration. Based on the results of steps 5
and 6, some architecture alternatives may be eliminated, one or more of the remaining
architectures may be modified and represented in more detail, and then the ATAM
steps are reapplied.

Architecture Assessment

The scene: Doug Miller’s office
as architectural design modeling
proceeds.

The players: Vinod, Jamie, and Ed, members
of the SafeHome software engineering team.
Also Doug Miller, manager of the software
engineering group.

The conversation:
Doug: I know you guys are deriving a couple
of different architectures for the SafeHome
product, and that’s a good thing. I guess my
question is, how are we going to choose the
one that’s best?

Ed: I’m working on a call-and-return style,
and then either Jamie or I will derive an OO
architecture.

Doug: Okay, and how do we choose?

Jamie: I took a CS course in design in my
senior year, and I remember that there are a
number of ways to do it.

Vinod: There are, but they’re a bit academic.
Look, I think we can do our assessment and
choose the right one using use cases and
scenarios.

Doug: Isn’t that the same thing?

Vinod: Not when you’re talking about
architectural assessment. We already have a

complete set of use cases. So we apply each
to both architectures and see how the system
reacts, how components and connectors work
in the use case context.

Ed: That’s a good idea. Make sure we didn’t
leave anything out.

Vinod: True, but it also tells us whether the
architectural design is convoluted, whether the
system has to twist itself into a pretzel to get
the job done.

Jamie: Aren’t scenarios just another name for
use cases?

Vinod: No, in this case a scenario implies
something different.

Doug: You’re talking about a quality scenario
or a change scenario, right?

Vinod: Yes. What we do is go back to the
stakeholders and ask them how SafeHome is
likely to change over the next, say, 3 years.
You know, new versions, features, that sort of
thing. We build a set of change scenarios. We
also develop a set of quality scenarios that
defines the attributes we’d like to see in the
software architecture.

Jamie: And we apply them to the alternatives.

Vinod: Exactly. The style that handles the use
cases and scenarios best is the one we choose.

safehome

10.7.1 Architectural Reviews
Architectural reviews are a type of specialized technical review (Chapter 16) that
provide a means of assessing the ability of a software architecture to meet the system’s
quality requirements (e.g., scalability or performance) and to identify any potential

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 203

risks. Architectural reviews have the potential to reduce project costs by detecting
design problems early.

Unlike requirements reviews that involve representatives of all stakeholders, archi-
tecture reviews often involve only software engineering team members supplemented
by independent experts. However, software-based systems are built by people with a
variety of different needs and points of view. Architects often focus on the long-term
impact of the system’s nonfunctional requirements as the architecture is created.
Senior managers assess the architecture within the context of business goals and objec-
tives. Project managers are often driven by short-term considerations of delivery dates
and budget. Software engineers are often focused on their own technology interests
and feature delivery. Each of these (and other) constituencies must agree that the
software architecture chosen has distinct advantages over any other alternatives. There-
fore, a wise software architect should build consensus among members of the software
team (and other stakeholders) to achieve the architectural vision for the final software
product [Wri11].

The most common architectural review techniques used in industry are: experience-
based reasoning, prototype evaluation, scenario review (Chapter 8), and use of check-
lists. Many architectural reviews occur early in the project life cycle; they should also
occur after new components or packages are acquired in component-based design
(Chapter 11). One of the most commonly cited problems facing software engineers
when conducting architectural reviews is missing or inadequate architectural work
products, thereby making review difficult to complete [Bab09].

10.7.2 Pattern-Based Architecture Review
Formal technical reviews (Chapter 16) can be applied to software architecture and
provide a means for managing system quality attributes, uncovering errors, and avoid-
ing unnecessary rework. However, in situations in which short build cycles, tight
deadlines, volatile requirements, and/or small teams are the norm, a lightweight archi-
tectural review process known as pattern-based architecture review (PBAR) might be
the best option.

PBAR is an evaluation method based on architectural patterns7 that leverages the
patterns’ relationships to quality attributes. A PBAR is a face-to-face audit meeting
involving all developers and other interested stakeholders. An external reviewer with
expertise in architecture, architecture patterns, quality attributes, and the application
domain is also in attendance. The system architect is the primary presenter.

A PBAR should be scheduled after the first working prototype or walking skeleton8
is completed. The PBAR encompasses the following iterative steps [Har11]:

1. Identify and discuss the quality attributes most important to the system by
walking through the relevant use cases (Chapter 8).

2. Discuss a diagram of the system’s architecture in relation to its requirements.

7 An architectural pattern is a generalized solution to an architectural design problem with a
specific set of conditions or constraints. Patterns are discussed in detail in Chapter 14.

8 A walking skeleton contains a baseline architecture that supports the functional requirements
with the highest priorities in the business case and the most challenging quality attributes.

204 PART TWO MODELING

3. Help the reviewer identify the architecture patterns used and match the
system’s structure to the patterns’ structure.

4. Using existing documentation and past use cases, examine the architecture
and quality attributes to determine each pattern’s effect on the system’s
quality attributes.

5. Identify and discuss all quality issues raised by architecture patterns used in
the design.

6. Develop a short summary of the issues uncovered during the meeting, and
make appropriate revisions to the walking skeleton.

PBARs are well suited to small, agile teams and require a relatively small amount
of extra project time and effort. With its short preparation and review time, PBAR
can accommodate changing requirements and short build cycles and, at the same time,
help improve the team’s understanding of the system architecture.

10.7.3 Architecture Conformance Checking
As the software process moves through design and into construction, software engi-
neers must work to ensure that an implemented and evolving system conforms to its
planned architecture. Many things (e.g., conflicting requirements, technical difficul-
ties, deadline pressures) cause deviations from a defined architecture. If architecture
is not checked for conformance periodically, uncontrolled deviations can cause archi-
tecture erosion and affect the quality of the system [Pas10].

Static architecture-conformance analysis (SACA) assesses whether an implemented
software system is consistent with its architectural model. The formalism (e.g., UML)
used to model the system architecture presents the static organization of system compo-
nents and how the components interact. Often the architectural model is used by a proj-
ect manager to plan and allocate work tasks, as well as to assess implementation progress.

10.8 su m m a ry

Software architecture provides a holistic view of the system to be built. It depicts the
structure and organization of software components, their properties, and the connec-
tions between them. Software components include program modules and the various
data representations that are manipulated by the program. Therefore, data design is
an integral part of the derivation of the software architecture. Architecture highlights
early design decisions and provides a mechanism for considering the benefits of alter-
native system structures.

Architectural design can coexist with agile methods by applying a hybrid architec-
tural design framework that makes use of existing techniques derived from popular
agile methods. Once an architecture is developed, it can be assessed to ensure con-
formance with business goals, software requirements, and quality attributes.

Several different architectural styles and patterns are available to the software engi-
neer and may be applied within a given architectural genre. Each style describes a
system category that encompasses a set of components that perform a function required
by a system; a set of connectors that enable communication, coordination, and coop-
eration among components; constraints that define how components can be integrated

CHAPTER 10 ARCHITECTURAL DESIGN—A RECOMMENDED APPROACH 205

to form the system; and semantic models that enable a designer to understand the
overall properties of a system.

In a general sense, architectural design is accomplished using four distinct steps.
First, the system must be represented in context. That is, the designer should define
the external entities that the software interacts with and the nature of the interaction.
Once context has been specified, the designer should identify a set of top-level abstrac-
tions, called archetypes, that represent pivotal elements of the system’s behavior or
function. After abstractions have been defined, the design begins to move closer to
the implementation domain. Components are identified and represented within the
context of an architecture that supports them. Finally, specific instantiations of the
architecture are developed to “prove” the design in a real-world context.

Pro b l e m s a n d Po i n t s to Po n d e r

10.1. Using the architecture of a house or building as a metaphor, draw comparisons with
software architecture. How are the disciplines of classical architecture and the software archi-
tecture similar? How do they differ?

10.2. Present two or three examples of applications for each of the architectural styles noted
in Section 10.3.1.

10.3. Some of the architectural styles noted in Section 10.3.1 are hierarchical in nature, and
others are not. Make a list of each type. How would the architectural styles that are not
hierarchical be implemented?

10.4. The terms architectural style, architectural pattern, and framework (not discussed in this
book) are often encountered in discussions of software architecture. Do some research, and
describe how each of these terms differs from its counterparts.

10.5. Select an application with which you are familiar. Answer each of the questions posed
for control and data in Section 10.3.3.

10.6. Research the ATAM (using [Kaz98]), and present a detailed discussion of the six steps
presented in Section 10.7.1.

10.7. If you haven’t done so, complete Problem 8.3. Use the design approach described in this
chapter to develop a software architecture for the pothole tracking and repair system (PHTRS).

10.8. Use the architectural decision template from Section 10.1.4 to document one of the
architectural decisions for PHTRS architecture developed in Problem 10.7.

10.9. Select a mobile application you are familiar with, and assess it using the architecture
considerations (economy, visibility, spacing, symmetry, emergence) from Section 10.4.

10.10. List the strengths and weakness of the PHTRS architecture you created for Problem 10.7.

Design element: Quick Look icon magnifying glass: © Roger Pressman