These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20051Software Engineering: A Practitioner’s Approach, 6/eWVU LDCSEECS 430Fall 2004copyright © 1996, 2001, 2005R.S. Pressman & Associates, Inc.For University Use OnlyMay be reproduced ONLY for student use at the university levelwhen used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20052Why Architecture?The 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, and (3) reduce the risks associated with the construction of the software.These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20053Why 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. 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].These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20056Data Design—Component Level1. The 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. A data dictionaryshould be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late inthe design process. 5. The representation of data structure should be known only to those modules that 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 to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types.These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20057Architectural Styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architecturesEach 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20058Data-Centered ArchitectureThese courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 20059Data Flow ArchitectureThese courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 200510Call and Return ArchitectureThese courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 200511Layered ArchitectureThese courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 200512Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism  operating system process management pattern task scheduler pattern Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common:  a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture an application level persistence pattern that builds persistence features into the application architecture Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment A broker acts as a ‘middle-man’ between the client component and a server component.These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 200513Architectural Design The software must be placed into context the design should define the external entities (other systems, devices, people) that the software interacts with and the natureof the interaction A set of architectural archetypes should be identified An archetype is an abstraction (similar to a class) that represents one element of system behavior The designer specifies the structure of the system by defining