Architectural design process Sub- systems and modules System - PDF document

Architectural Design Objectives • To introduce architect ural design and to discuss it s importance • Establishing the overall • To explain why multiple models are required to document a sof tware structure of a sof tware architecture • To describe types of architectural system models that may be used • To discuss how domain- specif ic ref erence models may be used as a basis f or product- lines and to compare sof tware architectures What is sof tware architecture? Topics covered • System structuring • The design process f or identif ying the sub- systems making up a • Control models system and the f ramework f or sub- • Modular decomposition system control and communication is • Domain- specif ic architectures called architectural design • The output of this design process is a description of the sof tware architecture Advantages of explicit Architectural design architecture • An early stage of the system design • Stakeholder communication process – Architecture may be used as a f ocus of discussion by syst em stakeholders • Represents the link between • System analysis specif ication and design processes – Means that analysis of whether t he • Of ten carried out in parallel with system can meet its non- f unctional some specif ication activities requirements is possible • Large- scale reuse • I t involves identif ying major system – The architecture may be reusable components and their across a range of systems communications 1

Architectural design process Sub- systems and modules • System structuring • A sub- system is a system in its own – The system is decomposed into several right whose operation is principal sub- systems and communications independent of the services between these sub- systems are identif ied provided by other sub- systems • Control modelling • A module is a system component – A model of the control relationships between the dif f erent parts of the system is that provides services to other established components but would not normally • Modular decomposition be considered as a separate system – The identif ied sub- systems are decomposed into modules Architectural models Architectural models • Static st ructural model • Dif f erent architectural models may be produced during the design – shows the major system components process • Dynamic process model – shows the process struct ure of the • Each model presents dif f erent system perspectives on the archit ecture • I nterf ace model – def ines sub- system interf aces • Relationships model – E. g. , data- f low model Architectural styles Architecture attributes • Perf ormance • The architectural model of a – Localize operations to minimize sub- system system may conf orm to a generic communication architectural model or st yle • Security • An awareness of these styles can – Use a layered architecture with critical assets in inner layers simplif y the problem of def ining • Saf ety system architectures – I solate saf ety- critical components • However, most large systems are • Availability heterogeneous and do not f ollow a – I nclude redundant components in the architecture single architectural st yle • Maintainability – Use f ine- grain, self - contained components 2

System structuring Packing robot control system • Concerned with decomposing the Vision Vision system into interacting sub- systems system system • The architectural design is normally Object Object Arm Gripper expressed as a block diagram Arm Gripper identif ication identif ication controller controller controller controller presenting an overview of the system system system structure • More specif ic models showing how Packaging Packaging selection sub- systems share data, are selection system system distributed and interf ace with each other may also be developed Packing Conveyor Packing Conveyor system controller system controller The repository model CASE toolset architecture • Sub- systems must exchange data. This Design Code Design Code may be done in two ways: Editor Generator Editor Generator – Shared data is held in a central database or repository and may be accessed by all sub- systems Design Program Design Project Program Project – Each sub- system maintains its own database Translator Editor Translator Repository Editor Repository and passes data explicitly to other sub- systems • When large amounts of data are to be Design Report Design Report shared, the repository model of sharing Analyzer Generator Analyzer Generator is most commonly used Repository model Client- server architecture characteristics • Advantages • Distributed system model which shows how data and processing is distributed – Ef f icient way to share large amounts of data across a range of component s – Sub- systems need not be concerned with how data is managed • Set of stand- alone servers which provide – Centralized management e. g. backup, specif ic services such as print ing, data security, etc. management, etc. • Disadvantages • Set of client s which call on these – Sub- systems must agree on a repository data services model. I nevitably a compromise • Network which allows client s t o access – Data evolution is dif f icult and expensive servers – Dif f icult to distribute ef f iciently 3

Film and picture library Client- server characteristics • Advantages Client 1 Client 2 Client 3 Client 4 Client 1 Client 2 Client 3 Client 4 – Distribution of data is straightf orward – Makes ef f ective use of networked systems. May require cheaper hardware Wide- bandwidth Network Wide- bandwidth Network – Easy to add new servers or upgrade existing servers • Disadvantages Catalog Hypertext Catalog Hypertext Video Picture – No shared data model so sub- systems use Video Picture server server server server server server dif f erent data organization server server – Data interchange may be inef f icient – Redundant management in each server – No central register of names and services - Catalog Film clip Digitized Hypertext Catalog Film clip Digitized Hypertext it may be dif f icult to f ind out what servers f iles photographs web f iles photographs web and services are available Abstract machine model Version management system • Used to model t he interf acing of sub- Version management systems Version management • Organizes t he system into a set of layers (or abstract machines) each of which provide a set of services Object management Object management • Supports the incremental development of Database system Database system sub- systems in dif f erent layers. When a Operating system layer interf ace changes, only the Operating system adjacent layer is af f ect ed • However, of ten dif f icult to st ructure systems in t his way Control models Centralized control • A control sub- system takes responsibility • Are concerned with the control f low f or managing the execution of other between sub- systems. Dist inct f rom t he sub- systems system decomposit ion model • Call- return model • Centralized control – Top- down subroutine model where control – One sub- system has overall responsibility f or starts at the top of a subroutine hierarchy control and starts and stops other sub- and moves downwards. Applicable to systems sequential systems • Event- based control • Manager model – One system component controls the stopping, – Each sub- system can respond to externally starting and coordination of other system generated events f rom other sub- systems or processes. Can be implemented in sequential the system’s environment systems as a case statement. Applicable to concurrent systems. 4