CHAPTER 5 ARCHITECTURAL DESIGN SE211 SOFTWARE DESIGN

Size: px

Start display at page:

Download "CHAPTER 5 ARCHITECTURAL DESIGN SE211 SOFTWARE DESIGN"

Phillip Carson
5 years ago
Views:

1 CHAPTER 5 ARCHITECTURAL DESIGN SE211 SOFTWARE DESIGN Assist. Prof. Dr. Volkan TUNALI Faculty of Engineering and Natural Sciences / Maltepe University

2 OVERVIEW 2 SECTION 1 Architectural Design SECTION 2 Architectural Modeling Notations

3 SECTION 1 3 Architectural Design

4 Objectives 4 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

5 Topics 5 Architectural design, product design, and detailed design Architectural design influences The architectural design process Quality attributes Architectural design specifications

6 Generic Software Engineering Design SRS : Problem Design Document : Solution SRS Analyze SRS Analysis 6 A Generic Software Engineering Design Process Generate/Improve Candidate Architectures Evaluate Candidate Architectures Select Architecture [else] Finalize Architecture [adequate architecture] Generate/Improve Detailed Design Alternatives Architectural Design Evaluate Detailed Design Alternatives Select Detailed Design [else] Detailed Design [else] [adequate detailed design] Finalize Design [adequate architecture] Design Document

7 Architectural Design 7 Architectural design is the activity of specifying a program s major parts; their responsibilities, properties, and interfaces; and the relationships and interactions among them.

8 Architectural Design During Product Design 8 Architecture is often needed during product design to Judge feasibility Convince stakeholders their needs can be met Conduct tradeoff analyses Plan the project

9 Architectural versus Detailed Design 9 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?

10 Influence on Architectural Design 10 Code libraries and other assets Organizational structure Knowledge and experience of designers Architectures influence people and organizations too

11 Architectural Design Process 11 Architectural Design Process SRS : Problem SAD : Solution SRS Analyze SRS Generate/Improve Candidate Architectures Evaluate Candidate Architectures Select Architecture [else] [adequate architecture] Finalize Architecture SAD

12 Software Architecture Document (SAD) 12 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

Quality Attributes 13 A quality attribute is a characteristic or property of a software product independent of its function that is important in satisfying stakeholder

13 Quality Attributes 13 A quality attribute is a characteristic or property of a software product independent of its function that is important in satisfying stakeholder needs. Non-functional requirements Architectures have a big influence on quality attributes Development or operational attributes Techniques for using quality attributes (later)

14 Development Attributes 14 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

15 Operational Attributes 15 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

16 Notations for Architectural Specifications 16 Type of Specification Decomposition States Collaborations Useful Notations Box-and-line diagrams, class diagrams, package diagrams, component diagrams, deployment diagrams State diagrams 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

17 Interfaces 17 An interface is a communications boundary between entities. An interface specification describes the mechanism that an entity uses to communicate with its environment.

18 Interface Specifications 18 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.

19 Interface Specification Template 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

20 Semantic Specification 20 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.

21 Summary 1 21 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.

22 Summary 2 22 A variety of notations are used for architectural modeling. Interface specifications should include descriptions of a communication medium s Syntax, Semantics, and Pragmatics.

23 SECTION 2 23 Architectural Modeling Notations

24 Objectives 24 To present several notations for architectural modeling Box-and-line diagrams UML package diagrams UML component diagrams UML deployment diagrams To present UML common notations Notes Constraints Properties Stereotypes

25 Topics 25 Box-and-line diagrams UML common notations Packages and package diagrams Components and component diagrams Nodes, artifacts, and deployment diagrams

26 Box-and-Line Diagrams 26 Icons (boxes) connected with lines No rules governing formation Used for both static and dynamic modeling Good idea to include a legend

27 Box-and-Line Diagram Example 27 User Interaction Monitor and Repair Irrigation Control Startup AquaLush State AquaLush Configuration Legend Functional Component Data Store x x y y Interacts With x Reads & Writes y x Reads y

28 Box-and-Line Diagram Heuristics 28 Make box-and-line diagrams only when no standard notation is adequate. Keep the boxes and lines simple. Make symbols for different things look different. Use symbols consistently in different diagrams. Use grammatical conventions to name elements. Don t mix static and dynamic elements.

29 UML Notes and Constraints 29 Note A dog-eared box connected to model elements by a dashed line May contain arbitrary text Used for comments and specifications Constraint A statement that must be true of entities designated by model elements Written inside curly brackets Beside single model elements Beside a dashed line connecting several model elements

30 UML Properties and Stereotypes 30 Property Characteristic of an entity designated by a model element List of tagged values in curly brackets Tagged value: tag = value Boolean properties that are true may drop the value and equals sign Stereotype A model element given more specific meaning Shown with icons, colors, graphics Stereotype keywords between guillemots, for example «interface»

31 Common Elements Example 31 for each bulb if!bulb.ison() { bulb.turnon() return } for each bulb bulb.turnoff() Lamp MAX_AMPS = 20 { constant } click() { ordered } 1..5 «physical device» Bulb islit : boolean ison() : boolean turnon() turnoff()

32 UML Dependency Relations 32 A dependency relation holds between two entities D and I when a change in I (the independent entity) may affect D (the dependent entity). Examples: D uses I, D depends for compilation on I, D imports I Represented by dependency arrows: stereotyped dashed arrows

33 Dependency Relation Example 33 java::util::date java::util::timer «imports» «imports» Clock «calls» ClockDisplay

34 UML Packages 34 A UML package is a collection of model elements, called package members. The package symbol is a file folder Package name in tab if body is occupied, otherwise in the body Members shown in body or using a containment symbol (circled plus sign) Often connected by import or export dependency arrows

35 Package Diagrams 35 A UML package diagram is one whose primary symbols are package symbols. Useful for Static models of modules, their parts, and their relationships Architectural modeling

36 Package Diagram Example 36 Electrical Parts Switches Toggle Switch Three-Way Switch Dimmer Switch Wiring Two-Wire Three-Wire Four-Wire

37 Software Components 37 A software component is a reusable, replaceable piece of software. Component-based development is an approach in which products are designed and built using commercially available or custom-built software components.

38 UML Component Diagrams 38 A UML component is a modular, replaceable unit with well-defined interfaces. Component symbols are rectangles containing names Stereotyped «component» or have component symbol in upper right-hand corner A UML component diagram shows components, their relationships to their environment, and their internal structure.

39 UML Interfaces 39 A UML interface is a named collection of public attributes and abstract operations. Represented by a stereotyped class symbol (later) Represented by special ball and socket symbols Note: this use of the term interface is different from out previous use as a communications boundary.

40 Provided and Required Interfaces 40 A class or component realizes an interface when it includes its attributes and implements its operations. Provided interface Realized by a class or component Represented by a ball or lollipop symbol Required interface Needed by a class or component Represented by a socket symbol The assembly connector wires interfaces together.

41 Interface Symbols Example 41

42 Component Internal Structure 42 Components can contain other components or classes showing how they are built. A delegation connector ties a component interface to one or more internal classes or components that realize or use the interface. Solid arrows Stereotyped with «delegate»

43 Component Internals Example 43

44 Component Diagram Uses 44 Static models of software components (reusable and replaceable parts) Model program components Architectural models Detailed design models Relationship to environment Model internal structure of components

45 Logical and Physical Architecture 45 Logical architecture The configuration of a product s major parts and their relationships in abstraction from implementation as code on a real machine Physical architecture The realization of a product as code and data files residing and executing on computational resources UML deployment diagrams model physical architecture.

46 UML Artifacts 46 A UML artifact is any physical representation of data used or produced during development or operation. Examples: Files, documents, program code Artifacts have types and instances Represented by rectangles containing names Stereotyped «artifact» or have artifact symbol in upper right-hand corner Instances have underlined names, types do not Artifacts realize logical entities (classes, components, etc.)

47 UML Nodes 47 A UML node is a computational resource. Device A physical processing unit, such as a computer Execution environment A software system that implements a virtual machine, such as an operating system or language interpreter Represented in UML by box or slab symbols Stereotyped with «device» or «execution environment» Types and instances Types have names Instance have underlined labels of the form name : type Name or type may be suppressed, but not both

48 Node Symbols Example 48

49 Deployment Diagrams 49 A UML deployment diagram models computational resources, communication paths among them, and artifacts that reside and execute on them. Used to show Real and virtual machines used in a system Communication paths between machines Program and data files realizing the system Residence Execution

50 Deployment Diagram Rules 50 Computational resources are nodes Communication paths are solid lines between nodes May be labeled May have multiplicities and role names Artifact symbols may Appear within node symbols Be listed within node symbols Be connected to node symbols by dependency arrows stereotyped with «deploy»

51 Deployment Diagram Example 51 «device» ServerPC «artifact» GameServer 1 * «device» ClientPC TCP/IP RMI «deploy» «device» GameDataServer «DB» GameData Rules BoardImage TokenImage «artifact» GameClient

52 Summary 52 Box-and-line diagrams are used to make static and dynamic architectural models. Notes, constraints, properties, and stereotypes can be used in any UML diagram. Package diagrams are used to model modules and their parts. Component diagrams are used to model software components. Deployment diagrams are used to model physical architectures.

Introduction to Software Engineering. ECSE-321 Unit 9 Architectural Design Approaches

Introduction to Software Engineering ECSE-321 Unit 9 Architectural Design Approaches Requirement Elicitation Analysis (Software Product Design) Architectural Design Detailed Design Architectural Design