Download
1 / 61
640 likes | 1.11k Views
Software Engineering. Chapter 6 Architectural Design Dr.Doaa Samy. Modified from Sommer v il l e’s o riginals. Objectives. 2. Understand the importance of architectural design . Introduce to the architectural vie w s .
E N D
Software Engineering Chapter 6 Architectural Design Dr.DoaaSamy ModifiedfromSommerville’soriginals
Objectives 2 Understand the importance of architectural design. Introduce to the architecturalviews. Understand the decisions that be made during architectural design. Know the architectural patterns that are often used in different types of application system.
Architecture 3 Architecture:Floorplan
Software Design 4 Thesoftwaredesign processis composedof fourmain designactivities: Architecturaldesignthischapter. Datadesign. Componentdesign. Interfacedesign.
Software DesignDeliverables 5 Themain deliverablesof theSoftware Design are: Software architecture. Datastructures. Pseudocode. Interfacedesigns. SoftwareDesignDocument.
UML diagram of systemparts ArchitecturalDesign
Example:Architecturaldesignfor “Packing robot controlsystem” 20 ArchitecturalDesign
Software Architecture 6 ArchitecturalDesign:The design process concerned with understanding how a system should be organized and designing the overall structure of that system. Software Architecture model:Outputofthisdesign process, describes how the system is organized as a set of communicating components. ASoftwareArchitectureconsistsof: Elements(components) withcertainproperties/behaviors. Relationshipsbetweenthem. Descriptionofpermittedandforbiddeninteractions.
Architectural Design 7 It is the first stage in the software design process. It linksbetween specification and designprocess. Often carried out in parallel with someof the specificationactivities. However, this is not ideally. Itinvolvesidentifyingmain structural components in a system and the relationships between them.
Advantages ofExplicit Architecture 8 • Three advantages of explicitly designing and documenting software architecture: • Stakeholdercommunication • Architecture is a high-level presentation. So, it maybeusedasafocusofdiscussionbydifferent stakeholders. • Systemanalysis • Meansthatanalyzingofwhetherthesystemcanmeetitscritical non- functionalrequirements. • Large-scalereuse • System architecture is often the same for systems with similar requirements and so can support large-scale software reuse.
Architectural Representations 9 UML was designed for describing object-oriented systems, it is not concerned with the design process. Object classes are too close to be useful for architectural description. Simple, informal block diagrams showing components and relationships are the most frequentlyusedmethod. Boxes indicate to the components while arrowsmean that data and or control signals are passed from component to another in the direction of the arrows.
Boxand Line Diagrams 10 Block diagrams are an appropriate way of describing the system architecture during the design process. Although they are veryabstract, donotshowthenatureof relationshipsbetween components nor the components’ visible properties, they are useful for communication with stakeholdersand forprojectplanning.
Architectural Views 11 It is impossible to represent all relevant information about a system’s architecture in a single architectural model. Each model only shows one view or perspective of the system such as: logical view, process view, development view, and physical view. For both design and documentation, you usually need to present multiple views of the software architecture.
Architectural Stylesand Patterns 12 Thearchitecturalmodelofasystemmayconformto agenericarchitecturalpattern orstyle. Architectural Patterns/Styles capture the essence of an architecture that used in different software systems. An awareness of these styles can simplify theproblemof defining systemarchitecture. However,mostlargesystemsareheterogeneousand donotfollowa singlearchitecturalstyle. Youdon’t have to reinvent thewheel!
Architectureand SystemCharacteristics 13 • A particular architectural style that you choose for a system should depend on the non-functional requirements (System Characteristics): • Performance • If it is critical, uselargeand few components less communications. • Security • If it is critical, usealayeredarchitecturewithcriticalassetsintheinnermostlayer withhighlevel of validationinthislayer. • Safety • If it is critical, put safety-criticalfeaturesinoneorsmallnumberofsub- systemsto reducescostsintheevent offailure. • Availability • If it is critical, include redundant components update without stop. • Maintainability • If it is critical, useseparate componentsand avoid shared data structure.
Architectural Design Decisions. 16 Thesoftwarearchitect mustmakedecisionsabout: Systemorganization(structure)style. Decompositionstyle. Controlstyle. Evaluating differentarchitecturesfora softwareis sometimesrefereedto asTradeoff analysis.
1. System Organization 17 Reflectsthe basic strategythatis usedtoorganizea system. Threearchitectural styles arewidelyused: Anabstract machine orlayeredstyle; Ashareddata repositorystyle; Aclient/serverstyle.
Layered Architecture 18 Usedtomodelthe interfacing of sub-systems. Organizes the system into a set of layers (or abstractmachines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. Each layer provides a set of services to the layeraboveandservesasaclient tothelayer below.
Example:AbstractmachinemodelforVersion managementsystem 30 ArchitecturalDesign
Advantages & Disadvantages ofLayered Style 21 Advantages: Supportsincrementaldevelopment. Changeable(ifalayerchanges,onlyadjacentlayersareaffected). Disadvantages: Structuringsystemsintolayersisdifficult. Innerlayersmayprovidesfacilitiesrequiredbyalllayers(e.g. filemanagement). Performanceisdegraded.
RepositoryStyle 22 Sub-systemsmust exchange data. This may be done in two ways: Shareddata isheldinacentraldatabaseorrepositoryandmaybeaccessedbyallsub-systems; Eachsub-systemmaintainsitsowndatabaseandpassesdata explicitlytoothersub-systems. When? large amounts of data are to be shared, the repository model ofsharing is most commonly used.
Advantages & Disadvantages of RepositoryStyle 23 Advantages: Efficientwaytosharelargeamountsofdata; Sub-systems neednot be concerned with how data isproduced; Centralizedmanagemente.g.backup,security,etc. Sharingmodelispublishedastherepositoryschema. Disadvantages: Sub-systemsmustagreeon arepositorydatamodel; Dataevolutionisdifficultandexpensive; Noscopeforspecificmanagementpolicies; Difficulttodistributeefficiently.
Client-Server Architecture 25 Distributedsystem modelwhichshowshowdataand processingisdistributed acrossarangeof components. Setofstand-alone serverswhichprovidespecificservicessuch as printing,datamanagement,etc. Setofclientswhichcallontheseservices. Networkwhichallowsclientstoaccessservers. Client and server exchange data for processing.
Advantages & Disadvantages of Client–Server 26 Advantages: Serverscanbedistributedacrossanetwork. Generalfunctionality(e.g. printingservice)can be available to all clients and does not need to be implemented by allservices. Easyadd newserverorupgradeexistingone. Disadvantages: Securityproblem,eachserverwillbesuspectedifafault happen. Performancemaybeunpredictablebecauseitdependsonthe networkaswellasthesystem. Management problems with servers owned by different organizations.
Object modelsdecomposition ArchitecturalDesign
Example: Object models for Invoice processingsystem ArchitecturalDesign
Object modelsdecomposition • Advantages: • Loosecouplingensuresthat changesinoneobjectclassdoesnot affect otherobjects • Sinceobjects tendtoreflectreal-world entities,objectmodels are easy tounderstand • Disadvantages: • Changes to the interface of an object have an impact on other users of theobject • Complex entities may be difficult to represent asobjects ArchitecturalDesign
DecompositionStyles 28 Wewill coverone modulardecompositionmodels Pipe andfilter or data-flow model where the system isdecomposedintofunctionalmoduleswhichtransforminputs tooutputs. Not Really suitable to interactive systems.
PipelineModel 29 Input Function Output 31
Pipeand FilterArchitecture 30 Functional transformations process theirinputs to produceoutputs. The processingofthedatainasystemisorganized so thateachprocessingcomponent(filter) is discrete and carries out onetypeofdata transformation.The data flows (as in a pipe) from one component to anotherforprocessing.
The Pipe and Filter Pattern 33 • Advantages: • Easytounderstandandsupportstransformationreuse. • Workflow style matches the structure of many businessprocesses. • Evolutionbyaddingtransformationsisstraightforward. • Can be implemented as either a sequential or concurrent system. • Disadvantages: • Not really suitable for interactive systems. • Although simple textual input and output can be modeled in this way, graphical user interfaces have more complex I/O formats which difficult to translated into a form compatible with the pipelining model.
Controlmodels • Refers to the control flow between sub-systems (not the same as system decompositionmodel) • Centralizedcontrol • Onesub-systemhasoverall responsibilityforcontrolandto start/shutdown othersub-systems • Event-basedcontrol • Each sub-system can respond to externally generated events; these events may come from other sub-systems or the system environment ArchitecturalDesign
Centralisedcontrol • One sub-system is responsible for managing the execution of othersub-systems. • Depending on whether the controlled sub-system executes sequentially or in parallel, the centralized control models maybe: • Call-returnmodel:Applicabletosequentialsystems.Controlstartsat the top of the hierarchy, and passes to lower level processes via functioncalls • Managermodel:Applicableto concurrentsystems.Controlledby a designated manager system component that coordinates other processes ArchitecturalDesign
Centralized control: Call-returncontrol model ArchitecturalDesign
Centralized control: Manager controlmodel ArchitecturalDesign
Example: Manager control model for Real-time systemcontrol 46 ArchitecturalDesign
