> 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 infor 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 271
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 userinterface 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
<<navigation link>> view BillOfMaterials
<<navigation link>> recommend component(s)
<<navigation link>> return to Room
<<navigation link>> purchase ProductComponent
<<navigation link>> purchase ProductComponent
<<navigation link>> request alternative
<<navigation link>> purchase ProductComponent
<<navigation link>> 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 screensize 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 information 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.pdf
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
