Software Architecture

Definition of Software Architecture (IEEE 1471-2000)
The fundamental organization of a system [as] embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.


Where does software architecture fit in?

Rational Unified Process (RUP)

Software architecture becomes increasingly important as the size of the code base and project increases. This doesn't mean that you should neglect the architecture of a project until it becomes too difficult to manage. In the context of the Rational Unified Process (RUP), the architecture would be considered between the requirements and implementation phases, effectively during the analysis and design stage. In terms of the design, the architecture can be viewed as the top-level design which is then further elaborated upon in the detailed design (Class diagrams, System Sequence diagrams, etc...). Naturally, since the architecture can be viewed as the top-level design, and fits into the RUP just after the requirements phase has commenced, a highly dependent relationship exists between the two phases. As we've seen above, architecture can be viewed as a form of design, but it should be noted that not all design activities are architectural activities. The levels of  design, from the top-most layer are, architectural design, detailed design and lastly the implementation (executable designs).

Benefits of an Architectural Design
- Reduced rates of failure
- Qualify rationale for architectural decisions
- Outline and mitigate risks
- Schedule and cost projects more effectively
- Useful for learning about the system
- Re-use of architectural styles
- Increases maintainability

Requirements Versus Design

Requirements Artifacts	Design Artifacts
Domain Model	Software Architecture Document
Use-Cases	Design Model
Non-Functional Requirements	User-Interface Design

How To Start Your Design
A natural way to begin the design is to build on some of the work that you've already put in. The domain model is an excellent place to create the first approximation of the design  as it guides the designers into crafting a solution with a minimal representational gap. Whenever tasked with creating a design for a software project always consider whether this same type of application has been created in the past. If so, then analyze how the current solutions are implemented and make use of whatever code or structure is available. Quite often an architectural style will have already been applied to the problem which you may likely want to re-use.

Common Architectural Styles
Data-Flow	Data-Centered	Virtual Machine	Call and Return	Independent Components
Pipes and Filters	Repository	Interpreter	Main Program and Subroutine	Communicating Processes
Batch Sequential	Blackboard	Rule-Based System	Object-Oriented (& Data Abstraction)	Client/Server
			Layered	Event Systems
				Implicit Invocation
				Explicit Invocation

Conceptual Integrity
"I will contend that Conceptual Integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."

- The Mythical Man-Month, by Fred Brooks, 1975


Enterprise Applications
Generally, enterprise applications form a class of software solutions that deal with large volumes of complex data that is persistent and concurrently accessed by many users and or applications. The software does not usually have strong hardware/software integration requirements. A common approach to constructing enterprise applications is to use the layered or client-server architecture.


Enterprise Application Architectural Styles
As we've just seen, two very common architectures are often employed in the construction of enterprise applications. We'll now take a closer look at both styles.

Layered Architecture
At the most basic level, the layered approach typically consists of at least three layers: presentation,  domain and data source. As far as functionality is concerned in the this architecture, lower level layers service requests from higher ones, thus providing functionality upwards from the bottom. Dependencies however move in the opposite direction from higher level layers to lower ones. One variation of the classic layered style exists, the pure layered style, where the dependencies are further restricted by allowing higher level layers to depend solely on services from components within the same layer or the layer immediately below.

Presentation 

------------------------------

Domain

------------------------------

Data Source

Client-Server Architecture
Client server applications, such as a web browser will usually utilize the Internet for communications. We'll provide a few quick definitions of what exactly we mean when we say the Internet versus the web. The Internet is the hardware infrastructure in which the web operates. The web is just software along with a set of associated protocols. As an example, Hyper-Text Transport Protocol (HTTP) is a stateless and fairly simple request-response protocol that is used extensively on the web. Now that the Lingua Franca has been defined we can better understand the interaction between the clients and servers. A client is responsible for sending HTTP requests to severs, while servers have the task of sending HTTP responses. A web server is a piece of software which implements the web protocols (i.e. HTTP). The clients (more software) make requests using the web protocol to the web servers and receive responses. Web servers can only serve static content, thus helper applications are needed in order for the server to serve dynamic content. An example of one such helper is a Java Servlet. The typical environment in which Java servlets reside is Tomcat, a servlet container. In the weakest possible terms the role of Tomcat is to facilitate the interaction between the web sever and the servlets. Tomcat

HTTP Methods	Description
GET	get a resource a given URL
POST	basically a GET with extra parameters
HEAD	GET the header part of the response only
TRACE	loopback request message
PUT	put info at given URL
DELETE	delete the given URL
OPTIONS	list the HTTP methods the URL can respond to
CONNECT	This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

The anatomy of an HTTP request, picture by Dr. Chalin

The anatomy of an HTTP response, Dr. Chalin

Pipes and Filters
The metaphor of pipes and filters can be directly applied as a software architectural style. A pipe carries a fluid through it until it reaches a filter. The filter then outputs it's modified fluid back into another pipe. In using this metaphor  as a basis for the software implementation say that a pipe should carry data between filters and a filter should accept data and output it to a pipe. The advantages of using this data flow style is that it assumes concurrent processing since output from a pipe can be continuously consumed by a filter while simultaneously outputting it's content to another pipe and ultimately filter. Each filters is independent all other filters, thus each filter maintains it's own state. Filters are thought of black boxes and are only responsible for accepting input in a specific format and outputting data in a specific format, thus filters can be swapped easily. No complex interactions exists in pipes, simple data transfers are the only responsibility of pipes. Some weaknesses of this style are that it's use can lead to batch sequential programming, it is also not well suited for interactive applications. As mentioned a data format must be defined for the input and output of the filters, thus additionally complexity is added to the filters for the encoding of decoding of outputs.

Variations of Pipes and Filters
Pipeline: A linear sequence of filters.
Batch Sequential System: A pipeline in which each filter runs to completion before the next begins.
Bounded Pipes: Restriction on the amount of data that can be temporarily in a pipe.
Types Pipes: The data passed between two filters is restricted to a well-defined type.
UI Pipes: Each filter is associated with a user-interface to allow the user to set parameters of operation.


Event-Based Architecture
Event-based programming is the chief architecture used in the development of graphical user interfaces. Someone clicks a button for instance and an event is fired notifying someone else that the button has been pressed and action must now be taken. It is also well suited for multi-core systems since events can be processed in a number of locations. UML2 has even made provisions for it within it's specification.

Components and Connectors
A component is an active or passive object, capsule or module. A connector is a callback, channel or binding. Notable component types are publishers and subscribers. A component does not explicitly invoke another component, instead an event is generated (message is passed). In order for a component to become aware of events stemming from another component it must subscribe or register with component. This relationship can be thought of as subscribing to a newsletter for instance. I must register myself on the subscribers list in order to be notified of updates. Once I am notified I can take whatever action I choose, read, disregard, forward, etc... A connector is tasked with carrying events being signals or messages from one component to another. Connectors can have a range of multiplicities with components, ranging from one-to-one to one-to-many, or many-to-one. The advantage of using this style is that it encourages code reuse through low coupling and provides opportunities for evolution as new components are introduced. Asynchronous communication is handled extremely well within this type of design. All of the weaknesses that arise in this architectural style stem from the lack of control components have over event processing. Components are restricted to simply generating events while a framework is tasked with the event dispatching. Furthermore, respondents to events are not ordered, sometimes making global system analysis more challenging. Asynchronous events explicitly highlight this problem. ow can we ensure that at least one object has processed an event? Another weakness associated with this style is a problem arising from the exchange of data between components which can lead to a resources management challenge.

Process Control
This architectural style is particularly well suited for modeling physical control systems. In this model software interacts with peripheral devices like sensors and actuators in order to control physical systems. This architecture can be applied in real-time, continuous, adaptable (load balancing) and control system environments. The disadvantages of this architectural style are that the reuse of components are often confined to one particular domain of the application and it can become difficult to adapt when are two or more interdependent processes to control.


Architectural Views

4+1 View Model

When analyzing the architecture of a system it is often most useful to consider the aspects of it relative to a particular view. A view is a fairly intuitive term in terms are architecture, it implies looking at something from a specific view-point. Naturally a single view-point cannot provide anyone with a complete picture, unless it is one dimensional, which large software projects are not.

"4 + 1" View Model of Architecture
This is one of the most popular view models conceived for software projects by Phillipe Kruchten in 1995.

View	Description	Artifacts
Logical View	The logical view is where the overall structure of the application is conveyed. Another way to characterize the logical view is to think of it as the interfaces to the environment in the most general of contexts.	- Package Diagrams - Class Diagrams - State Diagrams - Interaction Diagrams
Process View	The process view is used to paint a picture describing the underlying processes and tasks which are occurring within the system, as well as the channels of communication between them. The interrelationships amongst processes should be visible as well as the synchronization mechanisms.	- Class Diagrams - State Diagrams - Interaction Diagrams - Component Diagrams
Deployment View	The deployment view, sometimes called the physical view, is used to describe the hardware and software setup that is required by the system. In this view we gain an appreciation of how the hardware and software components are combined to form the deployed product.	- Deployment Diagrams
Implementation View	The implementation view, sometimes called the development view, provides perspective on the software's organization. The components of the system as well as their inter-dependencies are outlined within this view. Libraries, sub-systems, executables, object files, etc. are all commonly documented components in this view. The relationships are denoted through containment and dependencies, thus providing a high-level vantage point for observing the software's organization.	- Package Diagrams
Use Case View	The use case view takes it's place prominently in the middle of the above 4+1 view model diagram, and rightfully so. It is the use cases which necessitated the system in the first place thus any model would be incomplete without it's raison d'être. Each system is designed to satisfy the needs of some target user, and the use case view elaborates on the systems utility from the users perspective. Note that not all use cases will be represented here, only those with the most architectural significance.	- Use Case Diagrams

Siemens Four View Model
This view model prescribes activities that should be carried out within each view. The activities are, global analysis, central analysis and final analysis.

Global Analysis
1) Analyze factors
2) Identify Issues
3) Create Strategies

The purpose of global analysis is to identify issues early in the architecture so that strategies can be proposed to resolve them. Factors are further decomposed into the following three categories: Product, Organizational, Technological. Issues simply implies a potential problem or risk. Strategies alludes to a means by which an issue is resolved.

Organizational factors can be further decomposed into the following top level groupings:
management, staff skills, process and development environment, development schedule and finally the development budget.

Product factors are:
Functional features, user interface, performance, dependability, failure detection (reporting and recovery), service and product cost.

Design Principles
Definition of a good design: A good design satisfies all of the requirements and passes all tests. It is also as simple as possible and conveys intent. There is no duplication and it's easy to understand, verify, extend and evolve.

Fundamental software design principles:
- Information hiding (Parnas)
- Protected Variations (Larman)
- Open-Closed Principle (Meyer)
- Separation of Concerns (Dijkstra, Parnas)
- High cohesion (GRASP)
- Low coupling (GRASP)

Object Oriented Design Principles
Design based on responsibility assignment
- GRASP (Larman)
- Responsibility-Driven Design, RDD (Wirfs-Brock et. al.)
- Class-Responsibility Collaboration Card Design Technique (Kent Beck, Ward Cunningham)

General Responsibility Assignment Principles (GRASP)

Controller

Creator

Indirection

Information Expert

High Cohesion

Low Coupling

Pure Fabrication

Protected Variations

Polymorphism

Software Design Patterns
GoF Design Patterns

Behavioral Patterns	Creational Patterns	Structural Patterns
Chain of responsibility	Abstract Factory	Adapter
Command	Builder	Bridge
Interpreter	Factory Method	Composite
Iterator	Prototype	Decorator
Mediator	Singleton	Facade
Memento		Flyweight
Observer		Proxy
State
Strategy
Template Method
Visitor

Data Source Software Design Patterns

Row Data Gateway (RDG)

Table Data Gateway (TDG)

Active Record

Data Mapper

Document Object Model (DOM)
The document object model describes the structure of a document in a hierarchical context. Consider an HTML page, it is organized as a tree of tags, where the first tag is <html> and last tag is </html>. Thus this tag is the root of the tree which is then followed by the <head> and <body> tags. More complicated hierarchies of tags arise when we begin to consider cascading style sheets. They allow stylistic hierarchies to be created for web content and stored separately from the content itself, providing a layer of indirection. The tags in an HTML page can be generalized to the concept of nodes of which the following types exist.

DOM Node Types:
- Document
- Element
- Attribute
- Text
- Comment

Architectural Definition Languages
This field is currently under continuous research and has not yet come to reach it's full potential. The concept here is to create a new higher level language that could serve to define both the structure and behavior of a program leading to executable code. I should point out that the scenario of producing executable code has not yet been completely realized. At the moment the best that can usually be done is creating the skeletons of the classes with method and attribute placeholders that would later be filled in. Some applications of code generation however have been quite successful, Boeing reported to have generated 75% of the code that was developed for their new 747. A closely related field is Model Driven Architecture (MDA) and Model Driven Design (MDD). The most notable of players in the market is IBM with it's Rose platform.

There will be more to come on this post... very soon.

Usability Engineering

Overview

Human Computer Interaction and Interaction Design

The goal of usability engineering is to optimize the user experience within your applications. Ideally the customer should be able to interact with your product in a manner that feels most natural to them. This is much easier said than done when considering the diversity of an applications user base, especially as the internet continues to proliferate. In order to maximize the quality of the user experience we will take an in depth look at the various activities that a software engineer should take in order to produce the highest quality application, in terms of user interaction and experience. The diagram on the right shows all of the different disciplines that relate to human computer interaction (HCI). As you can see there are a lot of professionals related to this practice, thus forming a well rounded team with specialists from as many disciplines as possible is a great way to generate good ideas within your team.

Good and Bad Designs
In order to appreciate good designs perhaps it would be helpful to first look at some bad designs. We have all seen bad designs before, the vending machine the scammed you, the remote control that was too complicated to use. Bad designs come along a lot more of then good designs since considerable effort is required to produce a design that is universally praised by a majority of the user base.  Basically a bad design does not lead the user naturally through workflows within the system, causing considerable confusion and frustration. A good design easily allows the user to recognize which actions need to be taken in order to achieve their goals. I would encourage you to see some proof of bad design in everyday life so that you can see for yourself how rampant bad designs are.

Traits of a Good User Interface
- Helps the user quickly build a mental model of the entire system, not just one part.
- Enables the user to easily build a mental model of the application, leading to intuition for the users.
- Feels natural to user making it easy to learn how to use. Removes any surprises that may cause confusion.
- Feels like it's been tailored to the end-user.
- Allows the user to perform tasks efficiently.
- Meets the principal design goals of: usability, catering to different types of users, etc...

The Tangible Benefits of a Good User Interface
- Enhances the users productivity.
- Reduces the learning curve and associated costs.
- Enhances the end-users' satisfaction.
- Improves the quality of the work performed by the users.
- Minimizes the the number of errors related to workflow processes.

Things You Need to Know to be Able to Produce a Good UI Design
Since we are concerned with the performance of the system relative to our end-users, it is only natural that we focus on them. The following list represents traits of our users that can help guide our UI design choices.

- Users profile, behavior, background, skill level, etc...
- The types of tasks that the user needs to perform.
- The context and social environment in which the system will be used.
- The limitations of what is suitable and feasible from a technological perspective.


The Difficulties of Producing a User Interface Design
Diversity amongst the users base as well as plethora of tasks which need to be performed compound to make the job of the UI designer that much more difficult. Additionally, understanding user requirements is not an easy process, as visible through the large number of software project failures. Additionally, when software begins it's lifetime, UI often takes a back seat since it's the last layer on the cake, although this is not recommended from a usability engineering perspective. The final and most decisive hurdle to most companies getting need to overcome in achieving a high quality UI is the cost associated with the process of researching, prototyping and testing.


The Status Quo From a Software Engineers Perspective (Note this is not acceptable)
- Let us design for technology rather than for the end-user needs.
- Flashy graphics and nice colors to make up for bad design.
- Engineers obsess over program logic while users interact with the application visually.
- Users make errors but we don't plan for them.
- Fix UI bugs with documentation
- Lack of time and budget, so improvements get pushed to the next release, perpetually in some cases.

Tips for Understanding Your Users' Needs
- Take into account your users strengths and weaknesses.
- Consider ways to help your users adopt more efficient work flows.
- Take the time to quantify what how to improve the quality of the user experience.
- Ask people what they want, and don't forget to listen to the answers.

"you cannot design the user experience, you can only design for a user experience"

The Interaction Design Process, Briefly

- Identify the needs and requirements for the suer experience.

- Develop alternative designs to meet these goals.

- Build interactive prototypes that can be evaluated.

- Continuously evaluate what is being produced based on the quality of the user experience.

Core Characteristics of Interaction Design

- Users are involved throughout the development process

- Specific usability and user experience goals must be identified, documented and agreed to by all parties.

- The design process occurs iteratively with time alloted for regular prototype evaluations.

Important Terms for Usability Designers
- Visiblity, i.e. making the actions that a user can perform visible to them.
- Affordance, referring to an attribute of an object that allows people know how to use it, i.e. door handles, computer mice, etc...
- Conceptual model, this is a high-level description of how a system is organized and operates.
- Models, a simplification of some aspect of human-computer interaction intended to make it easier for designers to predict and evaluate alternative designs.
- Framework, a set of interrelated concepts and/or a set of specific questions.

Usability Principles (Nielson 2001)
- Visibility of system status
- Mach between system and the real world
- User control and freedom
- Consistency and standards
- Help users recognize, diagnose and recover from errors
- Error prevention
- Recognition rather than recall
- Flexibility and efficiency of use
- Aesthetic and minimalist design
- Help and documentation


Understanding User Interaction
So far we've highlighted the goals of user interaction design, and have seen what makes a good or bad design. We'll now switch our focus a bit towards understanding how to analyze the problem space (user requirements) so that when we do get to the point of designing out solution we will have a better idea of what problem we are trying to solve.

Analyzing the Problem Space
In order to effectively analyze the problem space we need to keep the following questions in mind.
- What do you want to create?
- What are your assumptions?
-  What are your claims?
- Will your solution effectively aid the user in achieving their goals, and how so?

Analyzing the Problem Space Related to Currently Implemented Solutions?
- Are there problems with an existing solution
- Why do you think there are problems within the existing solution?
- How do you think your proposed design ideas can overcome these issues?
- when designing for a new user experience how will the proposed design extend or change current workflows?

Creating a Conceptual Model
As defined above, the conceptual model is the high level design description of how the system will operate. This is extremely important to do at the beginning of the design process since it will help formulate the overall strategy for the solution to be. By establishing a conceptual model a lot of questions that may arise during the design process can be managed with the overall goal in mind allowing the designers to create a more cohesive solution.

Main Components of a Conceptual Model
- Major metaphors and analogies that are used to convey what the solution has been designed for and how it should be used.
- Concepts that users are exposed to in using the product.
- The relationships between the concepts.
- The mappings between the concepts and the user experience the product is designed to support.

Interface Metaphors
Using a metaphors in your design helps foster intuition amongst users. An effective metaphor allows the uses to grasp the underlying conceptual model with ease. It can also be an innovative way to make your application accessible to more users. A good metaphor is designed to be similar to some familiar physical entity, like a desktop. By likening your virtual solution to some physical entity you can allow the users to build their own intuition quickly about how the product performs.

Difficulties in Creating Interface Metaphors (Nielson, 1990)
- Break conventional and cultural rules (i.e. recycle bins on desktops).
- Can constrain designer in the way which they conceptualize the problem space.
- Conflict with design principles.
- Forces users to only understand the system in terms of the metaphor.
- Designer can inadvertently use bas existing designs and transfer the bad parts over.
- Limits the designers' imagination in creating new conceptual models.

Interaction Types (M.I.C.E.)
The following is a categorization of the various interaction types.
- Instructing: Issuing commands using the keyboard, function keys and selecting options from a menu.
- Conversing: Interacting with the system as if having a conversation with it.
- Manipulating: Interacting with objects in a virtual or physical space by manipulating them.
- Exploring: Moving through a virtual environment or space.

Understanding Users
There are two types of cognition according to Norman (1993), experiential and reflective. Experiential cognition is defined as the type of cognitive exercise where a person is mindlessly interacting with his or her environment. Reflective cognition is when  you deliberately think about an issue and make a decision about it. The reason that it is important to make this distinction is because each type of cognitive process requires different levels of technological support. One thing to keep in mind about all of this is that people have been proven to be much better at recognizing things than recalling them. Additionally, certain types of information are easier to recognize than others, such as pictures. This leads us to the concept of recall-directed memory versus recognition-based scanning. Suppose the user of your system was trying to go to a URL that they were recently at. The first attempt of the user is to remember the URL directly and simply type it in to the navigation bar. When this fails the user resorts to scanning his history for the proper URL since he was there just a few days ago. Although scanning takes longer than remembering something directly the end result was ultimately achieved. This shows us that it is important to provide your users with a couple different ways of locating items of interest in order to provide the most enjoyable user experience. A general strategy when  implementing some of these ideas into a UI is to use recognition rather than recall within menus, icons and consistently placed objects.

Theory of Action (Norman 1996)
The following theory is an approximation of the mental process which occurs in each of us when using software. This theory suggests that software should always provide it's users with meaningful responses in order to inform them whether or not their needs and intentions have been met.

Bridging the gulfs of execution and evaluation, Norman 1986

1) Establish a goal
2) Form an intention
3) Specify an action sequence
4) Execute an action
5) Perceive the system state
6) Interpret the state
7) Evaluate the system state with respect to the goals and intentions





Data Gathering Techniques
1) Interviews
     - Structured
     - Semi-structured
     - Unstructured
2) Focus Groups
3) Questionnaires
4) Observation
     - Field
     - Controlled environment