Design Software II Some Enabling Techniques
Identify the Software Architecture
Decompose System into Modules
Module is a single executable file that is only a part of the
application Decomposing and modularizing large software into a number of smaller independent ones, usually with the goal of placing different functionalities or responsibilities in different components Modules are abstractions that should
be independent
have well-specified interfaces
have high cohesion and low coupling
Coupling and cohesion
Coupling is defined as the strength of the relationships
between modules
Cohesion is defined by how the elements making up a
module are related
As described above, we should maximize internal cohesion
and minimize external coupling of modules during the decomposition of a system
Determine Relations Between Modules
Identify module dependencies
Determine the form of inter-module communication
global variables
parameterized function calls
shared memory
RPC or message passing
Specify Module Interfaces
Interfaces should be well-defined
Describe Module Functionality
Informally (comments or documentation)
Formally (via module interface specification languages)
Modularity
A module interface consists of several sections
Imports Services requested from other modules Exports Services provided to other modules
Access Control
Heuristics for determining interface specification define one specification that allows multiple implementations anticipate change e.g., use structures and classes for parameters
Criteria for Evaluating Modular Designs (1/2)
Modular Decomposability
Does the method aid decomposing a new problem into several
separate sub-problems? (e.g., top-down functional design)
Modular Composability
Does the method aid constructing new systems from existing
software components? (e.g., bottom-up design)
Modular Understandability
Are modules separately understandable by a human reader, e.g.,
how tightly coupled are they?
Criteria for Evaluating Modular Designs (2/2)
Modular Continuity
Do small changes to the specification affect a localized and
limited number of modules?
Modular Protection
Are the effects of run-time abnormalities confined to a small
number of related modules?
Architectural patterns
Architectural Patterns (1/2)
Definition of Pattern
If something is strictly described and commonly available, it is a
pattern
An architectural pattern expresses a fundamental
structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations
Although an architectural pattern conveys an image of a system,
it is not an architecture An architectural pattern is rather a concept that captures essential elements of a software architecture
Architectural Patterns (2/2)
One of the most important aspects of architectural patterns is that they
embody different quality attributes
For example, some patterns represent solutions to performance problems
and others can be used successfully in high-availability systems In the early design phase, a software architect makes a choice of which architectural pattern(s) best provide the system's desired qualities
The commonly used architectural patterns include
Presentation-abstraction-control Three-tier Pipeline Implicit invocation Blackboard system Peer-to-peer Service Oriented Architecture Naked objects Model-View-Controller
Three-Tier (1/3)
Multi-tier architecture (often referred to as n-tier
architecture) is a client-server architecture in which an application is executed by more than one distinct software agent
For example, an application that uses middleware to service
data requests between a user and a database employs multi-tier architecture
The most widespread use of "multi-tier architecture" refers
to three-tier architecture
Three-Tier (2/3)
Three-tier is a client-server architecture in which the user interface, functional
process logic, computer data storage and data access are developed and maintained as independent modules
Presentation Tier
This is the top most level of the application. The presentation tier displays information
related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.
Application Tier/Logic Tier/Business Logic Tier
The logic tier is pulled out from the presentation tier and, as its own layer, it controls an
application's functionality by performing detailed processing
Data Tier
This tier consists of Database Servers. Here information is stored and retrieved. This tier
keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
Three-Tier (1/3)
(3/3)
Peer-to-peer A peer-to-peer computer network uses diverse
connectivity between participants in a network and the cumulative bandwidth of network participants rather than conventional centralized resources where a relatively low number of servers provide the core value to a service or application A pure peer-to-peer network does not have the notion of clients or servers, but only equal peer nodes that simultaneously function as both "clients" and "servers" to the other nodes on the network
Peer-to-peer (2/3)
Peer-to-peer networks can be classified by what they can be
used for
file sharing telephony media streaming (radio, video) discussion forums
Advantage
An important goal in peer-to-peer networks is that all clients
provide resources, including bandwidth, storage space, and computing power
Peer-to-peer (3/3)
Unstructured P2P
An unstructured P2P network is formed when the overlay links are
established arbitrarily The networks can be easily constructed as a new peer that wants to join the network can copy existing links of another node and then form its own links over time If a peer wants to find a desired piece of data in the network, the query has to be flooded through the network to find as many peers as possible that share the data The main disadvantage with such networks is that the queries may not always be resolved (ex: rare data)
Structured P2P
employs a globally consistent protocol to ensure that any node can
efficiently route a search to some peer that has the desired file, even if the file is extremely rare
Service Oriented Architecture (SOA) (1/2)
SOA is an architectural style that guides all aspects of creating and using
business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications
SOA represents a model in which functionality is decomposed into
distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications
These services communicate with each other by passing data from one
service to another, or by coordinating an activity between two or more services
Roles in SOA (2/2)
Each SOA building block can play one or more of three roles
Service provider Service broker The service broker, also known as service registry, is responsible for making the Web service interface and implementation access information available to any potential service requestor Service requestor
Model-view-controller (1/4)
In complex computer applications that present a large
amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface
The model-view-controller solves this problem by
decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller
Model-view-controller (2/4)
Controller
View
Model
Model-view-controller (3/4)
Model
The domain-specific representation of the information that the
application operates. Domain logic adds meaning to raw data (e.g., calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model
Model-view-controller (4/4)
View
Renders the model into a form suitable for interaction, typically
a user interface element. Multiple views can exist for a single model for different purposes
Controller
Processes and responds to events, typically user actions, and
may invoke changes on the model
MVC is often seen in web applications, where the view is the
actual HTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML. Finally, the model is represented by the actual content, usually stored in a database or XML files
Three-Tier vs. Model-view-controller
They are topologically different
A fundamental rule in a three-tier architecture is the
client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier
Conceptually the three-tier architecture is linear
For MVC, the View sends updates to the Controller, the
Controller updates the Model, and the View gets updated directly from the Model
MVC architecture is triangular