Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Design.

Similar presentations


Presentation on theme: "© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Design."— Presentation transcript:

1 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Design

2 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2 Objectives  To discuss the relationships between architectural design and product and detailed design  To list influences on architectural design  To review the architectural design process  To present the contents of a software architecture document (SAD)  To explain quality attributes and their role in architectural design  To survey architectural specification notations, especially those for interfaces

3 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 3 Topics  Architectural design, product design, and detailed design  Architectural design influences  The architectural design process  Quality attributes  Architectural design specifications

4 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 4 Architectural Design Architectural design is the activity of specifying a program’s major parts; their responsibilities, properties, and interfaces; and the relationships and interactions among them.

5 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 5 Architectural Design During Product Design Architecture is often needed during product design to Judge feasibility Convince stakeholders their needs can be met Conduct tradeoff analyses Plan the project

6 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6 Architectural versus Detailed Design Often the distinction between architectural and detailed design is not clear. What is a “major” program part? How abstract should architectural specifications be? What is the architecture of a very small program?

7 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7 Influence on Architectural Design  Code libraries and other assets  Organizational structure  Knowledge and experience of designers  Architectures influence people and organizations too

8 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 8 Architectural Design Process

9 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 9 Software Architecture Document (SAD) Contents  Product Overview—Product vision, stakeholders, target market, etc.  Architectural Models—Specification using various models, both static and dynamic DeSCRIPTR  Mapping Between Models—Tables and text relating models  Architectural Design Rationale—Explanation of difficult, crucial, puzzling, and hard-to- change design decisions

10 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 10 Quality Attributes  Non-functional requirements  Architectures have a big influence on quality attributes  Development or operational attributes  Techniques for using quality attributes (later) A quality attribute is a characteristic or property of a software product independent of its function that is important in satisfying stakeholder needs.

11 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 11 Development Attributes  Maintainability—Ease with which a product can be corrected, improved, or ported Often subdivided  Reusability—Degree to which a product’s parts can be reused in another product  Others

12 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 12 Operational Attributes  Performance—Ability to accomplish product functions within time or resource limits  Availability—Readiness for use  Reliability—Ability to behave in accord with requirements under normal operating conditions  Security—Ability to resist being harmed or causing harm by hostile acts or influences  Others

13 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 13 Notations for Architectural Specifications Type of SpecificationUseful Notations Decomposition Box-and-line diagrams, class diagrams, package diagrams, component diagrams, deployment diagrams States State diagrams Collaborations Sequence and communication diagrams, activity diagrams, box-and-line diagrams, use case models Responsibilities Text, box-and-line diagrams, class diagrams Interfaces Text, class diagrams Properties Text Transitions State diagrams Relationships Box-and-line diagrams, component diagrams, class diagrams, deployment diagrams, text

14 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 14 Interfaces An interface is a communications boundary between entities. An interface specification describes the mechanism that an entity uses to communicate with its environment. An interface is a communications boundary between entities. An interface specification describes the mechanism that an entity uses to communicate with its environment.

15 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 15 Interface Specifications  Syntax—Elements of the communications medium and how they are combined to form messages  Semantics—The meanings of messages  Pragmatics—How messages are used in context to accomplish tasks  Interface specifications should cover the syntax, semantics, and pragmatics of the communication between a module and its environment.

16 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 16 Interface Specification Template 1.Services Provided For each service provided specify its a) Syntax b) Semantics c) Pragmatics 2.Services Required Specify each required service by name. A service description may be included. 3.Usage Guide 4.Design Rationale

17 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 17 Semantic Specification  A precondition is an assertion that must be true at the start of an activity or operation.  A postcondition is an assertion that must be true at the completion of an activity or operation.  Pre- and postconditions can together specify what happens when an operation executes, thus explaining its semantics.

18 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 18 Summary 1  Architectural design must usually begin during product design to help product feasibility.  Architectural design may shade into detailed design.  A SAD contains an overview, architecture specifications, and design rationale.  Architectural decisions greatly influence quality attributes.

19 © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 19 Summary 2  A variety of notations are used for architectural modeling.  Interface specifications should include descriptions of a communication medium’s Syntax, Semantics, and Pragmatics.


Download ppt "© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Design."

Similar presentations


Ads by Google