Architectural Requirements Phase. See Sommerville Chapters 11, 12, 13, 14, 18.2

Transcription

1 Architectural Requirements Phase See Sommerville Chapters 11, 12, 13, 14,

2 Architectural Requirements Phase So7ware requirements concerned construc>on of a logical model Architectural requirements concern construc>on of a physical model Architecture bible : M. Shaw & D. Garlan, So#ware Architecture, Pren>ce Hall,

3 Architectural Design Concerns physical system par>>oning alloca>on of tasks to components high cohesion and low coupling = good / robust low cohesion and high coupling = bad / fragile high cohesion (high element dependence inside components) low coupling (low component interdependence, so design is robust against change) component interface design component reuse choice of architecture to meet performance and other nonfunc>onal requirements problem solu>on by divide and conquer 3

4 Architecture Design Process Mostly, we will instan>ate a well known global architecture, as well as sub architectures and design pa;erns by top down refinement all the way down to unit level. 4

5 Architecture Criteria (1) Is there a generic architecture or pavern that can be a template for the system or component? (Otherwise ad hoc.) (2) How will the system be distributed across hardware to achieve performance, security, reliability etc? (3) Which generic architectures provide different alterna>ves, and what are the tradeoffs? (tradeoff analysis) 5

6 Architecture (cont.) (4) How can each component be decomposed into sub components (divide and conquer, maximise reuse, cohesion vs. coupling) (5) How to implement control and co opera>on (6) How to evaluate the design? (predict performance?) (7) How to document the design (sta>c, dynamic, UML?) especially component interfaces so that coders can work to an interface 6

7 System Models Documenta>on depends on which kinds of system models we use: (1) Sta>c structural model (class or package diagram) (2) Dynamic process model run >me behavior (sequence diagram, statechart) (3) Interface model (class diagram, OCL, JML) (4) Rela>onship model (data flow diagram) (5) Distribu>on model across hardware (package diagram) (6) Tes>ng model define integra>on tests (JUnit, JBehave, TTCN) 7

8 Architecture 1: Client Server Client * * Server requester provider service1() service2() servicen() Request for service using RPC or CORBA, Java RMI, HTTP, etc. 8

9 Architecture 2: Three Tier Database Architecture 3. Interface layer 2. Applica>on logic layer 1. Storage layer Interface layer: objects dealing with user, windows, forms, Web pages, etc logic layer: control and en>ty objects for processing, Rule checking and no>fica>on Storage layer: implements storage, retrieval and query of persistent objects 9

10 Architecture 3: Four Tier Database Architecture 4. Presenta>on Client Interface layer of 3 >ered 3. Presenta>on Server 2. Applica>on logic layer 1. Storage layer Presenta>on Client sits on user machine. Presenta>on Server sits on server machine Different kinds of clients and servers possible Compare with MVC! 10

11 Possible of 4. WebBrowser Interface layer 3. Server Side Form 2. DB Connection 1. SQL Query 11

12 Architecture 4: Layered Subsystems hierarchically organized, each layer (1) depending only on layer below, (2) supplying services to layers above (iterated client server?) 12

13 Possible Instan5a5on ISO/OSI 7 layer communica5on hierarchy 7. Applica>on (mail, telnet, 7p ) 6. Presenta>on (XDR) 5. Session (RPC) 4. Transport (TCP, UDP) 3. Network (IP) 2. Data Link (Ethernet) 1. Physical (thinnet, thicknet, UTP) Hardware level 13

14 Architecture 5: Data Centered Centralise around a large data collec>on, aka repository App1 App3 App2 14

15 Architecture 6 : Independent components Execu>ng in parallel, with communica>on, aka object oriented architectures. e.g. simple OOP, peer to peer (2 way client server) 15

16 Architecture 7: Model View Controller (MVC) An architectural model that solves many user interface (UI) problems, e.g. shared data, mul>ple users, different views of the same data, upda>ng informa>on across all users, changes to underlying data, changes to representa>on, changing UI technology. 16

17 MyView viewdata Model coredata setofobservers 1 depends on * initialize() displaydata() update() 1 attach(observer) detach(observer) notify() getdata() modifydata() 1 updates * 1 updates viewdata MyController initialize() changedata() update() 17

18 Architecture 8: Data Flow Data flows between sta>c func>onal elements which transform it, aka pipeline architecture e.g. compiler C code parse tree assembler Machine code Parse procedure calls Translate assembler Link & Assemble Library

19 Design Pa;erns Are the answer to a ques>on that commonly arises How can I? PaVerns record successful solu5ons in so7ware development for sharing between projects. Gang of Four (GoF) Gamma, Helm, Johnson, Vlissides, founders of movement. Gamma et al, Design PaJerns: Elements of Reusable Object Oriented So#ware, Addison Wesley, Literally thousands of paverns!

20 Types of Pa;ern Basically 3 types of pavern Crea@onal: address problems of crea>ng an object in a flexible way. Separate crea>on, from opera>on/use. Structural: address problems of using O O constructs like inheritance to organize classes and objects Behavioral: address problems of assigning responsibili>es to classes. Suggest both sta>c rela>onships and paverns of communica>on

21 Example Pa;ern: Mediator (Behavioral) Problem: How can we deal with two or more classes which some>mes interact, but can also be used separately? Mediator promotes loose coupling by keeping objects from referring to one another explicitly. Put each interac>on between objects in a separate (Mediator) class. This class should have references to the objects.

22 A pavern for two objects which exist independently but have some coupling. This coupling is placed in its own class. Used by e.g. ActionListener in Java which couples together two graphical objects, e.g. window & button. Colleagues send and receive requests from a Mediator object. The mediator implements the coopera>ve behavior by rou>ng requests between appropriate colleagues.

23 Mediator Structure Mediator 1 mediator Colleague ConcreteMediator * Concrete Colleague1 Concrete Colleague2 *

24 Comments Façade, unlike Mediator, abstracts a subsystem of objects to provide a convenient interface. Unidirec@onal. Façade objects make requests of the subsystem, but not viceversa. Mediator enables coopera>ve behaviour, that colleagues don t or can t provide. Mul@direc@onal.

25 PSS 05 ARD Template Sec>ons 1 and 2 are similar to SRD template. 3. System Context. Gives a detailed descrip>on of the system context, with relevant diagrams. Defines the external interfaces of the product under development for these other systems 3.n. External interface defini@on. Provides an interface defini>on to each separate external component type or physical component. 25

26 4 System Design. Provides an overview of the design techniques used, especially any in house or non standard nota>ons, project specific methods, or non standard interpreta>on of standard languages/methods such as UML/ Waterfall. 4.1 Design method. Describes and references the design method. Why we did what we did Gives the top level view of the systems design, preferably with diagrams. Shows the major components which will be described in detail in Sec>on 5. Iden>fies control and data flow between components. 26

27 5 Component Gives detailed component informa>on according to a fixed template. Components may be top level components, iden>fied in Sec>on 4.2, or subcomponents of these. Preferably use a component iden>fica>on scheme which is easy to read/follow/ remember. 5.n [Component iden@fier] Fill in name here. 5.n.1 Type. Could be a module, an input/output/temporary file, a program, a class, a script, a web page, etc. 5.n.2 Purpose. Describe the purpose of the component, and relate this to a numbered so7ware requirement in the SRD. 5.n.3 Func@on. Describe the func>onality of the component, including its interface proper>es (call and return types) and logical behaviour. 5.n.4 Subordinates. List the immediate subcomponents of the component, using defined component iden>fiers. 27

28 5.n.5 Dependencies. Describe the logical precondi>ons for using this component, e.g. files and/or objects which must exist. 5.n.6 Interfaces. Define the control and data flow to and from the object. Gives a detailed picture of its context in the overall system architecture. 5.n.7 Resources. List any resources required by the component, such as external components external subsystems, hardware, etc. 5.n.8 References. reference any documents needed to understand the component. 5.n.9 Processing. Describe the control and data flow betwen immediate subcomponents of this component. If the component has no immediate subcomponents (i.e. it is fully decomposed) then outline the method of processing used by the component to perform its task (e.g. with pseudo code, state diagrams, etc). 5.n.10 Data. Describe in detail (where possible) the local data values and data structures belonging to (local in scope) this component. Otherwise give an outline descrip>on. 28

29 6 Feasibility and Resource Summarize the conclusions of a feasibility study around the architectural model. Priori>ze all components using a priority model (e.g. economy, standard, deluxe versions). Iden>fy and describe all future project tasks. Iden>fy task dependencies in terms of commencement and comple>on, preferably with a task flow chart. Es>mate the effort required for each project task. Produce a task alloca>on plan and schedule for each project staff member for the remainder of the project. This informa>on should preferably be presented in a table. 29

30 Iden>fy possible risks going forward, and for each risk, give a risk management proposal. Es>mate the overall schedule for making a detailed design, coding this design, tes>ng and delivering the final product and documenta>on according to the project deadlines. Iden>fy the cri>cal path in the project, and analyze possible project slippage along this path. 7 So^ware Requirements vs Components Traceability Matrix. Gives a table cross referencing architectural components (based on defined component iden>fers). 30