Presentazioni simili

2
Design and Objectives the software design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. the software design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. the software design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. From Pressman

11
(Software) Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” Structural and behavior properties. This aspect of the architectural design representation defines the modules of a system (e.g., components, objects, filters) and the manner in which those modules are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other characteristics. Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks. From Pressman

13
Componente in UML “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”

14
What is the "right" number of components for a specific software design? optimal number of components of components cost of cost of software software number of components componentintegrationcost component development cost From Pressman

15
Why 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. From Pressman

16
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. 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 understandable model of how the system is structured and how its components (or modules) work together” [BAS03]. From Pressman

18
Architectural Styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures others Each style describes a system category that encompasses: (1) a set of modules (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. From Pressman Not unique!!

19

20
Data-Centered Architecture From Pressman

21
Data Flow Architecture From Pressman

22
Usual Call and Return Architecture From Pressman

23

24
Layered Architecture From Pressman

25

26

27
Architectural Patterns Concurrency — Software must handle multiple tasks in a manner that simulates parallelism – task scheduler pattern Persistence —Data persists if it survives past the execution of the component that created it. Two patterns are common: – a database management system pattern that applies the storage and retrieval capability of a DBMS to the Software – an application level persistence pattern that builds persistence features into the Software Distribution (and replication) — the manner in which components communicate with one another in a distributed environment – A broker acts as a ‘middle-man’ between the client component and a server component. From Pressman

28
Design Patterns The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution A description of a design pattern may also consider a set of design forces. – Design forces describe non-functional requirements – quality attributes - (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied. The pattern characteristics indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems. From Pressman

36
Structured Design Seeks to conquer the complexity of large systems through partitioning and hierarchical structuring. Uses graphical tools to render systems more understandable.

37
Structured Design Offers a set of strategies for developing a design solution from a well-defined requirement specifications. Offers a set of objective and empirically justified criteria for evaluating the quality of a given design solution with respect to the problem on hand.

39
Structure Chart A structure chart has three constituents: Modules Connections between modules Interactions between modules throughout parameter (data) passing and call/return among different module (which constitutes the “semantic model” of the architecture). Procedural (internal) aspects of modules (e.g, how a particular functionality is realised with programming languages) are not represented. Structure charts are easily turned in to software code using programming languages.

41
Characteristics of Structure Chart Abstraction: – Low levels modules cannot invoke higher level modules Fan-out: – Indicates how many modules are directly invoked by a given module – Low fan-out represents modules with simple functionality Fan-in: – indicates how many modules directly invoke a given module. – High fan-in represents code reuse and is in general encouraged (but not in the initial steps of the design).

42
Transformation of DFD diagrams in Structure Charts Two strategies exist to guide transformation of a DFD into a structure chart: – Transform Analysis – Transaction Analysis These two strategies are usually mixed for making the transformation of the whole DFD

43
Transform Analysis The first step in transform analysis: – divide the DFD into 3 parts input, logical processing, output. Usually all flows are required

44
The first step in transform analysis: – Find the transformation center where outputs flows are alternatives Usually all flows are required Usually flows are alternative based on the input flows and values Transformation center Transform Analysis afferent efferent

45
Transform Analysis: details A B C a b c d Root Get b Get aA BPut c Put dC b bc c c d d B is the transformation center Get and Put modules can be interfaces to terminators (read and write) Or can be modules to read and write data stores becomes

48
Transform Analysis Identifying the highest level input and output transforms: – requires experience and skill. Some guidelines: – follow (some) inputs until a function is found whose output cannot be deduced from these inputs alone. – functions which validate input are not central transforms. – functions which sort input or filter data from it are.

49
Transform Analysis First level of structure chart: – draw a module for each input and output function in the DFD – a module for the central transform. Next, refine the structure chart: – add sub modules required by each high-level module. – Many levels of modules may required to be added. Finally check: – whether all functions in the DFD have been mapped to modules.

51
Example 1: RMS Calculating Software From a cursory analysis of the problem description, easy to see that the system needs to perform: accept the input numbers from the user, validate the numbers, calculate the root mean square of the input numbers, display the result.

55
Example 2: Tic-Tac-Toe Computer Game As soon as either of the human player or the computer wins, – a message congratulating the winner should be displayed. If neither player manages to get three consecutive marks along a straight line, – and all the squares on the board are filled up, – then the game is drawn. The computer always tries to win a game.

66
It starts from an extended DFD Structure charts can be employed but they are not really suitable because the “control flow” (i.e. part of the “semantic model”) is fixed (and not defined in the DFD) while the “control flow” is explicitly provided in the extended DFD In principle an extended DFD can be mapped on process and event architectures

67
The usual OO Design Model From Pressman

68
Architectures in OO The main architectural style is layered (by definition), incrementing the class diagrams (from the analytical model) The structure of the architecture is usually represented by using components and package diagrams The “semantic model” of the architecture can be represented throughout sequence diagrams

71
Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism – task scheduler pattern Persistence—Data persists if it survives past the execution of the software 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 – an application level persistence pattern that builds persistence features into the application Distribution (and replication)—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. From Pressman

72
Design patterns in OO Design patterns in OO are the main mechanism for incrementing the class diagrams The same difference found when relating distinct notations in structured analysis and object-oriented requirement engineering is also found in the transition between requirement engineering and design engineering i.e. class diagrams are usually incremented, DFD are usually transformed

74
Analyzing Architectural Design 1.Collect scenarios. 2.Elicit requirements, constraints, and environment description. 3.Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements 4.Evaluate quality attributes by considered each attribute in isolation. 5.Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. From Pressman