1. ARCHITECTURAL DESIGN

2. Why is Architecture Important? Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the 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]. Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [BAS03].

3. Architectural design represents the structure of data and program components that are required to build a computer based system. Architecture is not the operational software. Rather it is a representation that enables 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 is still relatively easy (3)Reducing the risks associated with the construction of the software.

4. Representations of software architecture are an enabler for communication between all parties interested in the development of a computer based system. The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows, and as important on the 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.

5. Like other software engineering activities, data design creates a model of data and/or information that is represented at a high level of abstraction. This data model is then refined into progressively more implementation specific representations that can be processed by the computer based program. The structure of data has always been an important part of software design. At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. The data design activity translates the elements of the requirements model into data structures at the software component level. Data Design

6. At the architectural level … At the architectural level … Design of one or more databases to support the application architectureDesign of one or more databases to support the application architecture Design of methods for ‘mining’ the content of multiple databasesDesign of methods for ‘mining’ the content of multiple databases navigate through existing databases in an attempt to extract appropriate business-level information navigate through existing databases in an attempt to extract appropriate business-level information Design of a data warehouse—a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business Design of a data warehouse—a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business

7. Data design at the component level focuses on the representation of data structures that are directly accessed by one or more software components. A set of principles can be applied for data design. 1. Systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. Data dictionary should be established and used to define both data and program design.

8. 4. Low level design processes should be deferred until late in the design process. 5. Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure. 6. A library of useful data structures and operations should be developed. 7. A software design and its implementation language should support the specification and realization of abstract data types.

9. Architectural Styles The software that is built for computer-based systems exhibits one of the many architectural styles. Each style encompasses 1. a set of components, that perform a function required by the system 2. a set of connectors that enable communication, coordination and cooperation among components 3. constrains that define how components can be integrated to form the system 4. semantic models that enable a designer to understand the overall properties of a system

10. Architectural Styles Data-centered architectures Data-centered architectures Data flow architectures Data flow architectures Call and return architectures Call and return architectures Object-oriented architectures Object-oriented architectures Layered architectures Layered architectures

11. Data-Centered Architecture A data store resides at the centre of this and is accessed by other components that update, add, delete, modify within the store.

12. Data Flow Architecture This is applied when input data are to be transformed through a series of computational or manipulative components into output data.

13. Data Flow Architecture A pipe and filter pattern 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 of a specified form. However, the filter does not require knowledge of the working of its neighboring filters. If the data flow degenerates into a single line of transforms, it is termed batch sequential. This accepts a batch of data and then applies a series of sequential components to transform it.

14. Call and Return Architecture This style enables a software designer to achieve a program structure that is relatively easy to modify and scale Mini program/subprogram architectures. Remote procedure call architectures.

15. Layered Architecture A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.

16. Object oriented architecture The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing.

17. MAPPING Software requirements can be mapped to various requirements. The transition from information flow to program structure is accomplished as a part of six-step process.  Establish type of information flow  Flow boundaries indicated  DFD is mapped into program structure  Control hierarchy defined  Resultant structure refined using design measures and heuristics  Architectural description refined and elaborated

18. Two type of information flow are transform flow and transaction flow. In transform flow externalized data must be converted in to an internal form for processing. Information enters the system along paths that transform external data into an internal form and the paths are identified as incoming flow. Data moving along the paths after transformation are called outgoing flow. Overall data flow occurs in a sequential manner. In transaction flow, information flow is often characterized by a single data item, called transaction, that triggers other data flow along one of many paths.

19. TRANSFORM MAPPING It is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style.  Review fundamental system model  Review and refine data flow diagrams for the software  Determine whether the DFD has transform or transaction characteristics

20.  Isolate the transform center by specifying incoming and outgoing flow boundaries  Perform first level factoring  Perform second level factoring  Refine the first iteration architecture using design heuristics for improved software quality

21. Transform Mapping

22. Factoring

23. First Level Factoring main program controller input controller processing controller output controller

24. Second Level Mapping Second level factoring is accomplished by mapping individual transforms of DFD into appropriate modules within the architecture

25. TRANSACTION MAPPING  Review fundamental system model  Review and refine data flow diagrams for the software  Determine whether the DFD has transform or transaction characteristics  Identify the transaction center and flow characteristics along each action path  Map the DFD to a program structure amenable to transaction processing  Factor and refine the transaction structure and the structure of each action path  Refine the first iteration architecture using design heuristics for improved software quality

26. OBJECT ORIENTED DESIGN

27. Object oriented design transforms the analysis model created using object-oriented analysis in to a design model that serves as a blueprint for software construction Object oriented design transforms the analysis model created using object-oriented analysis in to a design model that serves as a blueprint for software construction An object-oriented system draws upon class definitions that are derived from the analysis model An object-oriented system draws upon class definitions that are derived from the analysis model OOD is divided into two major activities OOD is divided into two major activities System DesignSystem Design Object DesignObject Design

28. System design defines the product architecture (the system functions and classes encapsulated in the subsystems). System design focuses on the specification of three components: the user interface, data management functions, and task management facilities. Object design focuses on the internal details of the individual classes and the messaging scheme. The design specification document form the SEPA web site is applicable to OOD. The OOD projects must be reviewed to ensure quality.

29. Design for Object-oriented System The conventional Pyramid concept is introduced for OOD, which contains four layers

30. Responsibilities layer (highest layer - contains data structure detail and algorithmic detail for each object's attributes and operations) Message layer (establishes the internal and external interfaces for the system, including the details of communication among object collaborators) Class and object layer (contains class hierarchy including representations of each object) Subsystem layer (lowest level - contains representations of each of the subsystems and the necessary infrastructure that enable the software to achieve the customer's requirements)

31. Object-oriented Design Issues Decomposability - facility of design method that allows the designer to decompose the problem into easily solved subproblems Composability - degree to which design method ensures that modules constructed for one project can be reused in another Understandability - ease with which a component can be understood without examining other components Continuity - ability to isolate changes made in one module and restrict the propagation of changes to other modules Protection - architectural characteristic that reduces the propagation of side effects when errors occur

32. Object-Oriented System Design Process Partition the analysis model into subsystems. Subsystems should have well defined communication interfaces with few exceptions classes should collaborate within their subsystem Keep number of subsystems small partition subsystem internally to reduce complexity Identify concurrency dictated by the problem. Allocate subsystems to processors and tasks Allocate each subsystem to an independent processor (or) allocate subsystems to same processor and provide concurrency support through operating system features Develop user interface design

33. Choose basic strategy for implementing data management Management of data critical to the application itself creation of infrastructure for storage and retrieval of objects Identify global resources and control mechanisms to access them Design control mechanism for system (including task management) Consider how subsystem boundary conditions should be handled Review and consider trade-offs

34. The Object Design Object descriptions protocol description - object interface specified by defining each message an object can receive and the operation triggered by message (or) implementation description - shows implementation details for each operation implied a message passed to the object Designing algorithms and data structures algorithm categories: data manipulation, computation, monitors refinement of operation programs defined during OOA Design optimization

35. The Object Design Review object-relationship model to ensure implemented design leads to efficient resource utilization, add redundancy where necessary revise attribute data structures and related operation algorithms to improve processing efficiency create attributes to save derived information and avoid re-computation Modularity is important aspect of object-oriented design quality (the program design language should support object definition)

36. Describing Design Pattern Design Pattern Specification Components Name Intent Design forces motivating the pattern Solution that mitigates these design forces Classes required to implement the solution Responsibilities and collaborations among the solution classes Implementation suggestions Source code examples or templates Cross-references to related design patterns