• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Chapter Comments 10-1
Chapter
10
Architectural Design
CHAPTER OVERVIEW AND COMMENTS
The intent of this chapter is to provide a systematic approach for the derivation of the architectural design. Architectural design encompasses both the dataarchitecture and the program structure layers of the design model. A generalintroduction to software architecture is presented. Examples are presented toillustrate the use of transform mapping and transaction mapping as means of  building the architectural model using structured design approach.
10.1 Software Architecture
This section defines the term “software architecture” as a framework made up of the system structures that comprise the software components, their properties,and the relationships among these components. The goal of the architecturalmodel is to allow the software engineer to view and evaluate the system as awhole before moving to component design.
10.1.1 What is Architecture?
The architecture is not the operational software. Rather, it is a representation thatenables a software engineer to:(1) Analyze the effectiveness of the design in meeting its stated requirements,(2) Consider architectural alternatives at a stage when making design changes isstill relatively easy, and(3) Reduce the risks associated with the construction of the software.
10.1.2 Why is Architecture Important?
•
Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of acomputer-based system.
•
The architecture highlights early design decisions that will have a profoundimpact on all software engineering work that follows and, as important, onthe ultimate success of the system as an operational entity.
•
Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”[BAS03].
 
10-2 SEPA, 6/e Instructor’s Guide
10.2 Data Design
This section describes data design at both the architectural and component levels.At the architecture level, data design is the process of creating a model of theinformation represented at a high level of abstraction (using the customer's viewof data).
10.2.1 Data Design at the Architectural Level
The challenge is extract useful information from the data environment,particularly when the information desired is cross-functional.To solve this challenge, the business IT community has developed
data mining
techniques, also called
knowledge discovery in databases
(KDD), that navigatethrough existing databases in an attempt to extract appropriate business-levelinformation.However, the existence of multiple databases, their different structures, thedegree of detail contained with the databases, and many other factors make datamining difficult within an existing database environment.An alternative solution, called a
data warehouse
, adds on additional layer to thedata architecture.A data warehouse is a separate data environment that is not directly integratedwith day-to-day applications that encompasses all data used by a business.In a sense, a data warehouse is a large, independent database that has access tothe data that are stored in databases that serve as the set of applications required by a business.
10.2.2 Data Design at the Component Level
At the component level, data design focuses on specific data structures requiredto realize the data objects to be manipulated by a component.
refine data objects and develop a set of data abstractions
implement data object attributes as one or more data structures
review data structures to ensure that appropriate relationships have beenestablished
simplify data structures as required
 
Chapter Comments 10-3
Set of principles for data specification:1. The systematic analysis principles applied to function and behavior shouldalso be applied to data.2. All data structures and the operations to be performed on each should beidentified.3. A data dictionary should be established and used to define both data andprogram design.4. Low level data design decisions should be deferred until late in the designprocess.5. The representation of data structure should be known only to those modulesthat must make direct use of the data contained within the structure.6. A library of useful data structures and the operations that may be applied tothem should be developed.7. A software design and programming language should support thespecification and realization of abstract data types.
10.3 Architectural Styles and Patterns
Each style describes a system category that encompasses:(1) A set of components (e.g., a database, computational modules) that perform afunction required by a system,(2) A set of connectors that enable “communication, coordination andcooperation” 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 propertiesof a system by analyzing the known properties of its constituent parts.An architectural style is a transformation that is imposed on the design of anentire system.An
architectural pattern,
like an architectural style, imposes a transformation onthe design of an architecture.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 architecturerather than the architecture in its entirety.2. A pattern imposes a rule on the architecture, describing how the S/W willhandle some aspect of its functionality at the infrastructure level.3. Architectural patterns tend to address specific behavioral issues within thecontext of the architectural. 
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...