ُsoftware Architecture
اسلاید 1: Software ArchitectureN.L. Hsueh
اسلاید 2: OutlineBasic ConceptArchitecture StylesControl modelsModular decompositionDomain-specific architecturesDesign Pattern
اسلاید 3: Basic ConceptThe architecture of a system is a comprehensive framework that describes its form and structure – its components and how they fit togetherA bad architectural design for a building cannot be rescued by good construction; the same is true for softwareThere are styles of building and software architecture
اسلاید 4: Architectural design processSystem structuringThe system is decomposed into several principal sub-systems and communications between these sub-systems are identifiedControl modellingA model of the control relationships between the different parts of the system is establishedModular decompositionThe identified sub-systems are decomposed into modules
اسلاید 5: Sub-systems and modulesA sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.A module is a system component that provides services to other components but would not normally be considered as a separate system
اسلاید 6: Architectural modelsStructure, control and modular decomposition may be based on a particular model or architectural styleHowever, most systems are heterogeneous in that different parts of the system are based on different models and, in some cases, the system may follow a composite modelThe architectural model used affects the performance, robustness, distributability and maintainability of the system
اسلاید 7: System structuringConcerned with decomposing the system into interacting sub-systemsThe architectural design is normally expressed as a block diagram presenting an overview of the system structureMore specific models showing how sub-systems share data, are distributed and interface with each other may also be developed
اسلاید 8: Architectural Style
اسلاید 9: 1. Main Program With Subroutines
اسلاید 10: ControlInputShiftSortOutputstoreshiftssortedoutputProcedure callAccess to data structurei/oinput
اسلاید 11: 2. Abstract Data TypeControlInputStoreShiftSortOutputoutputoutput
اسلاید 12: StoreinitialStore: PutChar(r,w,c,d):CloseStore: it is called after all inputlines have been stored through successive calls of PutChar()Lines(): delivers the number of lines storesWords(r)Chars(r,w)Char(r,w,c)InputCall Store.initialStore()Read from input and call PutChar(…)Call CloseStore()
اسلاید 13: ShiftShiftLines()ShiftWords(l)ShiftChars(l,w)ShiftChar(l,w,c)SortiniSortgetIndex(w)
اسلاید 14: 3. Implicit InvocationControlInputMakeShiftSortOutputStoreShiftoutputImplicit callinputThe MakeShift module is no explicitly called
اسلاید 15: 4. Pipe and FilterInputShiftSortOutputinputoutput
اسلاید 16: 5. RepositorySub-systems must exchange data. This may be done in two ways:Shared data is held in a central database or repository and may be accessed by all sub-systemsEach sub-system maintains its own database and passes data explicitly to other sub-systemsWhen large amounts of data are to be shared, the repository model of sharing is most commonly used
اسلاید 17: Conti.
اسلاید 18: Conti.AdvantagesEfficient way to share large amounts of dataSub-systems need not be concerned with how data is produced Centralized management e.g. backup, security, etc.Sharing model is published as the repository schemaDisadvantagesSub-systems must agree on a repository data model. Inevitably a compromiseData evolution is difficult and expensive
اسلاید 19: 6. Layered
اسلاید 20: 7. Client-serverDistributed system model which shows how data and processing is distributed across a range of componentsSet of stand-alone servers which provide specific services such as printing, data management, etc.Set of clients which call on these servicesNetwork which allows clients to access servers
اسلاید 21: Conti.AdvantagesDistribution of data is straightforwardMakes effective use of networked systemsEasy to add new servers or upgrade existing serversDisadvantagesNo shared data model so sub-systems use different data organization. Data interchange may be inefficientNo central register of names and services - it may be hard to find out what servers and services are available
اسلاید 22: Control Model
اسلاید 23: Control modelsAre concerned with the control flow between sub-systems. Distinct from the system decomposition modelCentralized controlOne sub-system has overall responsibility for control and starts and stops other sub-systemsEvent-based controlEach sub-system can respond to externally generated events from other sub-systems or the system’s environment
اسلاید 24: 1. Centralized controlA control sub-system takes responsibility for managing the execution of other sub-systemsCall-return modelTop-down subroutine model Control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systemsManager modelOne system component controls the stopping, starting and coordination of other system processes. Applicable to concurrent systems.
اسلاید 25: Call-return model
اسلاید 26: A centralized control model for a real-time system control
اسلاید 27: 2. Event-driven systemsDriven by externally generated events where the timing of the event is outside the control of the sub-systems which process the eventIn centralized control models, control decisions are usually determined by the value of some system state variablesTwo principal event-driven modelsBroadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do soInterrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing
اسلاید 28: Broadcast modelEffective in integrating sub-systems on different computers in a networkSub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the eventControl policy is not embedded in the event and message handler. Sub-systems decide on events of interest to themHowever, sub-systems don’t know when an event will be handledSub-system K m1.registerTo(m2) m2 receive an event m2 will call m1
اسلاید 29: Broadcasting
اسلاید 30: Interrupt-driven systemsUsed in real-time systems where fast response to an event is essentialThere are known interrupt types with a handler defined for each typeEach type is associated with a memory location and a hardware switch causes transfer to its handlerAllows fast response but complex to program and difficult to validate
اسلاید 31: Interrupt-driven control
اسلاید 32: Modular Decomposition
اسلاید 33: The problem that they have to deal with are complex, …, software engineers cannot reduce this complexity. However, it can be funneled and confined within weakly coupled closed areas. By judicious segmentation of the state space, the system is made easier
اسلاید 34: Modular decompositionSub-systems are decomposed into modulesTwo modular decomposition models coveredAn object model where the system is decomposed into interacting objectsA data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline modelIf possible, decisions about concurrency should be delayed until modules are implemented
اسلاید 35: Object modelsStructure the system into a set of loosely coupled objects with well-defined interfacesObject-oriented decomposition is concerned with identifying object classes, their attributes and operationsWhen implemented, objects are created from these classes and some control model used to coordinate object operationsAdv:loosely coupled: the implementation of objects can be modified without affecting other objectsEasily modeled: objects are often representations of real-world entities
اسلاید 36: Invoice processing system
اسلاید 37: Data-flow modelsFunctional transformations process their inputs to produce outputsMay be referred to as a pipe and filter model (as in UNIX shell)Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systemsNot really suitable for interactive systemsAdv.It supports the reuse of transformationsIt is intuitive in that many people think of their work in terms of input and output processingEvolving the system by adding new transformations is usually straightforwardIt is simple to implement either as a concurrent or a sequential system
اسلاید 38: Invoice processing system
اسلاید 39: Domain-Specific Architecture
اسلاید 40: Domain-specific architecturesArchitectural models which are specific to some application domainTwo types of domain-specific modelGeneric models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systemsMay be reused directly in a designBottom-up modelsReference models which are more abstract, idealized model. Provide a means of information about that class of system and of comparing different architecturesUsed to communicate domain concepts and compare possible architectureTop-down models
اسلاید 41: Generic modelsCompiler model is a well-known example although other models exist in more specialized application domainsLexical analyzerSymbol tableSyntax analyzerSyntax treeSemantic analyzerCode generatorGeneric compiler model may be organized according to different architectural models
اسلاید 42: A data-flow model of a compiler
اسلاید 43: The repository model of a language processing system
اسلاید 44: Reference architecturesReference models are derived from a study of the application domain rather than from existing systemsMay be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluatedOSI model is a layered model for communication systems
اسلاید 45: OSI reference model
اسلاید 46: Design Pattern
اسلاید 47: 我們不只要做絲襪, 我們要做 ‘超彈性’絲襪
اسلاید 48: What is a Pattern?Current use comes from the work of the architect Christopher AlexanderAlexander studied ways to improve the process of designing buildings and urban areas“Each pattern is a three-part rule, which expresses a relation between a certain context, a problem and a solution.”Hence, the common definition of a pattern: “A solution to a problem in a context.”Patterns can be applied to many different areas of human endeavor, including software development
اسلاید 49: Why Pattern?Designing object-oriented software is hard and designing reusable object-oriented software is even harder. - Erich GammaExperienced designers reuse solutions that have worked in the pastWell-structured object-oriented systems have recurring patterns of classes and objectsKnowledge of the patterns that have worked in the past allows a designer to be more productive and the resulting designs to be more flexible and reusable
اسلاید 50: History1987 - Cunningham and Beck used Alexander’s ideas to develop a small pattern language for Smalltalk1990 - The Gang of Four (Gamma, Helm, Johnson and Vlissides) begin work compiling a catalog of design patterns1991 - Bruce Anderson gives first Patterns Workshop at OOPSLA1993 - Kent Beck and Grady Booch sponsor the first meeting of what is now known as the Hillside Group1994 - First Pattern Languages of Programs (PLoP) conference1995 - The Gang of Four (GoF) publish the Design Patterns book
اسلاید 51: Types of software patternsAnalysisDesignOrganizationalProcessProject PlanningConfiguration Management
اسلاید 52: Types of software patternsRiehle and Zullighoven in “Understanding and Using Patterns in Software Development” mention three types of software patternsConceptual PatternPattern whose form is described by means of terms and concepts from the application domainDesign PatternPattern whose form is described by means of software design constructs, such as objects, classes, inheritance and aggregationProgramming Pattern (Programming Idiom)Pattern whose form is described by means of programming language constructs
اسلاید 53: Design Pattern Level of AbstractionComplex design for an entire application or subsystemSolution to a general design problem in a particular contextSimple reusable design class such as a linked list, hash table, etc.More concreteMore abstract
اسلاید 54: GoF Design PatternsThe GoF design patterns are in the middle of these levels of abstraction“A design pattern names, abstracts, and identifies key aspects of a common design structure that makes it useful for creating a reusable object-oriented design.”The GoF design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”
اسلاید 55: GoF Classification Of Design PatternsPurpose - what a pattern doesCreational PatternsConcern the process of object creationStructural PatternsDeal with the composition of classes and objectsBehavioral PatternsDeal with the interaction of classes and objectsScope - what the pattern applies toClass PatternsFocus on the relationships between classes and their subclassesInvolve inheritance reuseObject PatternsFocus on the relationships between objectsInvolve composition reuse
اسلاید 56: GoF Essential Elements Of Design PatternsPattern NameHaving a concise, meaningful name for a pattern improves communication among developersProblemWhat is the problem and context where we would use this pattern?What are the conditions that must be met before this pattern should be used?SolutionA description of the elements that make up the design patternEmphasizes their relationships, responsibilities and collaborationsNot a concrete design or implementation; rather an abstract descriptionConsequencesThe pros and cons of using the patternIncludes impacts on reusability, portability, extensibility
اسلاید 57: GoF Pattern TemplateStructureA graphical representation of the patternParticipantsThe classes and objects participating in the patternCollaborationsHow to do the participants interact to carry out their responsibilities?ConsequencesWhat are the pros and cons of using the pattern?ImplementationHints and techniques for implementing the pattern
اسلاید 58: GoF Pattern TemplatePattern Name and ClassificationA good , concise name for the pattern and the patterns typeIntentShort statement about what the pattern doesAlso Known AsOther names for the patternMotivationA scenario that illustrates where the pattern would be usefulApplicabilitySituations where the pattern can be used
اسلاید 59: GoF Pattern TemplateSample CodeCode fragments for a sample implementationKnown UsesExamples of the pattern in real systemsRelated PatternsOther patterns that are closely related to the pattern
اسلاید 60: Key pointsThe software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition modelSystem decomposition models include repository models, client-server models and abstract machine modelsControl models include centralised control and event-driven models
اسلاید 61: Key pointsModular decomposition models include data-flow and object modelsDomain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models
اسلاید 62: The architectural model provides a Gestalt view of a system, allowing the software engineering to examine it as a wholeR. Pressma
نقد و بررسی ها
هیچ نظری برای این پاورپوینت نوشته نشده است.