Kĩ thuật lập trình - Lecture 4: Software architecture

Ivan MarsicRutgers UniversityLECTURE 4: Software Architecture*TopicsProblem Structure vs. Solution StructureSoftware Architecture DefinitionArchitectural Decisions & Key ConcernsArchitectural StylesDocumenting Architecture: ViewsHierarchical Organization of SoftwareSoftware is not one long list of program statements but it has structureTaxonomy of structural parts (abstraction hierarchy), but not representation of relationships between the partsand does not specify the function of each part*System or productSubsystems/ModulesPackagesClasses/ObjectsMethodshighest abstraction levellowest levelProduct line (or product family)Source codeBut first, why do we want to decompose systems?The hierarchy shows a taxonomy of the system parts, but not the procedure for decomposing the system into parts — how do we do it?*Why We Want ToDecompose SystemsTackle complexity by “divide-and-conquer”See if some parts already exist & can be reusedFocus on creative parts and avoid “reinventing the wheel”Support flexibility and future evolution by decoupling unrelated parts, so each can evolve separately (“separation of concerns”)Create sustainable strategic advantage*Problem StructureSubsystems derived from the requirements (“bottom-up” approach or induction)*Typical Software Eng. Problems1. User works with computer system (problem domain is “virtual”, not physical)2. Computer system controls the (physical) problem domain (user not involved)3. Computer system intermediates between the user and the problem domainUserSystemSystemProblem domainUserSystemProblem domainUserSystemRepositoryUserSystemProblem domainUserSystemProblem domainSystemIN docOUT doc1.a) System transforms input document to output document1.b) User edits information stored in a repository3.a) System observes the problem domain and displays information3.b) System controls the problem domain as commanded by the userREQ-1: Map input data to output data as said by given rulesREQ-2: Allow repository editing, where “repository” is a collection of dataREQ-3: Automatically control a physical object/deviceREQ-5: Monitor and display information about an objectREQ-4: Interactively control a physical object/device*Controlling subsystemControlled subsystem3.b) Commanded behavior:OperatorMonitoring subsystemMonitored subsystem3.a) Information display:DisplaySoftware (i.e., Solution) Architecture2. Required behavior:Controlling subsystemControlled subsystemFeeding subsystemTransformation subsystemReceiving subsystem1.a) Transformation:Data editorData repository1.b) Simple editing:UserSYSTEMSYSTEMSYSTEMSYSTEMSYSTEMSoftware Architecture DefinitionSoftware Architecture =a set of high-level decisions that determine the structure of the solution(parts of system-to-be and their relationships)Principal decisions made throughout the development and evolution of a software systemmade early and affect large parts of the system (“design philosophy”) — such decisions are hard to modify laterDecisions to use well-known solutions that are proven to work for similar problemsSoftware Architecture is not a phase of developmentDoes not refer to a specific product of a particular phase of the development process (labeled “high-level design” or “product design”)**Example Architectural DecisionsSubsystem for device controlSubsystem for administrationSubsystem for remote data accessOn embedded computerOn office desktopOn tenant’s smartphoneSafe Home Access SystemDecision on mapping software-to-hardwareDecision on system decompositionSuch decisions are made early on,perhaps while discussing the requirements with the customerto decide which hardware devices will be used for user interaction and device controlExample decisions:*Architectural Decisions—A matter of scopeProduct/system A scopeProduct B scopeProduct line scopeSubsystem scopeproduct or system architecture decisionsproduct line architecture decisionsGiven the current level of system scope, a decision is “architectural” if it can be made only by considering the present scopeI.e. could not be made from a more narrowly-scoped, local perspectiveArchitectural decisions should focus on high impact, high priority areas that are in strong alignment with the business strategysystemic impactlocal impactClass scope*Software ArchitectureKey ConcernsSystem decompositionhow do we break the system up into pieces?do we have all the necessary pieces?do the pieces fit together?Cross-cutting concernsbroad-scoped qualities or properties of the systemtradeoffs among the qualitiesConceptual integrity(Principal decisions to be made)*Architecture versus DesignArchitecture focuses on non-functional requirements (“cross-cutting concerns”) and decomposition of functional requirementsDesign focuses on implementing the functional requirementsNote: The borders are not always sharp!*Architectural Decisions Often Involve CompromiseThe “best” design for a component considered in isolation may not be chosen when components considered together orwithin a broader contextPlus, business priorities, available resources, core competences, target customers, competitors’ moves, technology trends, existing investments, backward compatibility, *Some Well-KnownArchitectural StylesWorld Wide Web architectural style:REST (Representational State Transfer)UNIX shell script architectural style:Pipe-and-FilterClient/ServerCentral Repository (database)Layered (or Multi-Tiered)Peer-to-PeerModel-View-Controller*Architectural Styles –Constituent PartsComponentsProcessing elements that “do the work”ConnectorsEnable communication among componentsBroadcast Bus, Middleware-enabled, implicit (events), explicit (procedure calls, ORBs, explicit communications bus) InterfacesConnection points on components and connectorsdefine where data may flow in and out of the components/connectorsConfigurationsArrangements of components and connectors that form an architecture*Architectural Style: Pipe-and-FilterComponents: Filters transform input into outputConnectors: Pipe data streamsExample: UNIX shell commandsfilterfilterfilterpipepipe% ls folder-name | grep –v match-string | more*Architectural Style: LayeredUser Interface LayerUser InteractionUser AuthenticationControl ofSensors and DevicesArchivingCommunicating alertsabout intrusionDomain Logic Layer(Business Rules)Technical ServicesLayera.k.a. Tiered Software Architecture*Architectural Style: Model-View-ControllerModel: holds all the data, state and application logic. Oblivious to the View and Controller. Provides API to retrieve state and send notifications of state changes to “observer”View: gives user a presentation of the Model.Gets data directly from the ModelController: Takes user input and figures out what it means to the Modeluserinput devicedisplayViewControllerModel5. I need your state (to display)1. The user did something2. Change your state3. Change your display4. I have changed*Model-View-ControllerControllerViewInputdeviceeventsEventInterpreterDomainmodelactionDomainModelModelVisualizerNotificationabout theeffects of theactionVisual feedbackof the alteredmodelUserUser InterfaceModel142631142631versusModel: array of numbers [ 14, 26, 31 ] Different Views for the same Model:*Subsystem for device controlSubsystem for administrationSubsystem for remote data accessApplication serverWeb browserWeb server Valid keys Access history Tenant profiles Central RepositoryArchitectural StyleReal System is a Combination of StylesTiered Architectural Style*Fitting the Parts TogetherInterface Specification SemanticsTo serve as a contract between component providers and clients, interfaces must befully documentedsemantics, not just syntaxunderstandable, unambiguous, preciseAdding semanticsinformal descriptiondesign models (e.g., UML interaction diagrams)pre/post conditions*Documenting Software Architecture: Architecture ViewsViews are different kinds of “blueprints” created for the system-to-beE.g., blueprints for buildings: construction, plumbing, electric wiring , heating, air conditioning, (Different stakeholders have different information needs)Module/Subsystem ViewsComponent and Connector ViewsAllocation Views*Module/Subsystem ViewsDecomposition ViewTop-down refinement (e.g., simple “block diagram”)Dependency ViewHow parts relate to one anotherLayered ViewSpecial case of dependency viewClass View“domain model” in OOA and “class diagram” in OOD*Component and Connector ViewsProcess ViewDefined sequence of activities?System represented as a series of communicating processesConcurrency ViewShared Data ViewClient/Server ViewE.g., in Web browsing*Allocation ViewsDeployment ViewSoftware-to-hardware assignmentImplementation ViewFile/folder structure – “package diagram”Work Assignment ViewWork distribution within the development team