1 / 54

Chapter 1 1 Architectural Design Instructor : Haya Sammaneh

Chapter 1 1 Architectural Design Instructor : Haya Sammaneh.

elina
Download Presentation

Chapter 1 1 Architectural Design Instructor : Haya Sammaneh

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 11Architectural DesignInstructor : Haya Sammaneh

  2. What is it? It is the structure of data and program components and interrelationships among all components. that required to build a computer-based system. Who does it?System engineersDBA (Database Administrator) system architects.

  3. Why is it?So, you need to look at the big picturebefore you worry about details. What are the steps?-It beginswith data design-Then proceed the data to derivation of one or more architectural structures of the system -Analyzed the architectural structures-Then select the best suited to customer requirements.

  4. How do we ensure that it is done right?Reviews for clarity, correctness, completeness, and consistency with requirement.

  5. Topics covered • System structuring • System organization • Control models • Modular decomposition styles • Domain-specific (reference) architectures

  6. Software architecture • The design process foridentifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design Software architecture • The hierarchical structure of program components, the manner in which these components interact and the structure of data that are used by these components.

  7. Advantages of explicitly designing and documenting a software architecture • Stakeholder communication, architecture may be used as a focus of discussion by system stakeholders • System analysis, means that analysis of whether the system can meet its non-functional requirements is possible such as performance and reliability. • Large-scale reuse, it is a compact, manageable description of how a system is organized and how the components interact and inter-operate, so the architecture may be reusable across a range of systems

  8. The choice of style and structure depends on the following: • Performance, use small number of large subsystem to minimize sub-system communication. • Security, use a layered architecture with critical assets and requirements in the inner layers • Safety,isolate safety-critical components within one sub system. • Availability, include redundant components in the architecture • Maintainability, use fine-grain (small sub system) that may readily be changed.

  9. Architectural conflicts • Using large-grain components improves performance but reduces maintainability. • Introducing redundant data improves availability but makes security more difficult.

  10. Architectural design process activities: • System organization (structuring), the system is decomposed into several principal sub-systems and communications between these sub-systems are identified (repository, client server, and abstract machine models) • Modular decomposition, the identified sub-systems are decomposed into modules(OO,DFD) • Control modeling (styles),the control relationships between the different parts of the system is established (centralized and event driven models)

  11. System structuring(system decomposition) • Concerned with decomposing the system into interacting sub-systems, each box in block diagram represent sub system. • The architectural design is normally expressed as a block diagram presenting an overview of the system structure, arrows mean thatdata and/or control is passed from sub system to another.

  12. Architectural styles • The architectural model of a system may conform to a generic architectural model or style. • However, most large systems are heterogeneous and do not follow a single architectural style.

  13. Architectural models • The output of the architectural design process is an architectural design document, which consists of a number of graphical representation of the system model. • Different architectural models may be produced during the design process • It should describe how the systemis structured intosub systems and how each sub system is structuredinto modules.

  14. Architectural models may include: • Static structural model that shows the major system components. • Dynamic process model that shows the process structure of the system. • Interface model that defines sub-system interfaces. • Relationships model such as a data-flow model that shows sub-system relationships. • Distribution model that shows how sub-systems are distributed across computers.

  15. 11.1 Architectural design decisions • Architectural design is a creative process so the process differs depending on the type of system being developed.

  16. Architecture reuse • Systems in the same domain often have similar architectures that reflect domain concepts.

  17. 11.2 System organization • Reflects the basic strategy that is used to structure a system. • Three organizational styles are widely used: • A shared data repository style; • A shared services and servers style; • An abstract machine or layeredstyle.

  18. 11.2.1 The repository model • Sub-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-systems • Each sub-system maintains its own database and passes data explicitly to other sub-systems • When large amounts of data are to be shared, the repository model of sharing is most commonly used.

  19. CASE toolset architecture

  20. Repository model characteristics • Advantages • Efficient way to share large amounts of data • Sub-systems need not be concerned with how data is produced • Centralized management e.g. backup, security, etc. • It is straight-forward to integrate new tools to a repository model.

  21. Disadvantages:. Data evolution is difficult as a large amount of data is generated, and translating this to new model is expensive, it may be impossible.. No scope for specific management policies, it forces the same policy on all sub system such as policies for backups, security, and recovery.

  22. 11.2.2 Client-server architecture • Distributed system model which shows how data and processing is distributed across a range of processors. • The major components are: • Set of stand-alone servers which provide specific services such as printing, data management, etc. • Set of clients which call on these services. • Network which allows clients to access servers.

  23. Clients may have to know the names of the available servers and the services that they provide. However, servers need not to know either the identity of the clients or how many clients there are.The following slide will present the architecture of a file and picture library system:

  24. Film and picture library

  25. Client-server characteristics • Advantages • Distribution of data is straightforward • Easy to add new servers or upgrade existing servers

  26. Disadvantages:. No shared datamodel so sub-systems use different data organization, each sub system manages its own data such as (backup and recovery), so data interchange may be inefficient.. Redundant management in each server.. No central register of names and services - it may be hard to find out what servers and services are available

  27. 11.2.3 Abstract machine model (layered model) • Organizes the system into a set of layers (or abstract machines) 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 • Performance also suffers because of multiple layers.

  28. Version management system

  29. 11.3 Modular decomposition styles • Another structural level where sub-systems are decomposed into modules, close to the system structuring but the components in modules are usually smaller than subsystems. • Two modular decomposition models covered • An object model where the system is decomposed into interacting objects • A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model

  30. Sub-systems and modules • A 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 be considered as a separate system

  31. 11.3.1 Object models • Structure the system into a set of loosely coupled objects with well-defined interfaces, the implementation of objects can be modified without affecting other objects. • Object-oriented decomposition is concerned with identifying object classes, their attributes and operations • When implemented, objects are created from these classes and some control model used to co-ordinate object operations

  32. Invoice processing systemفاتوره

  33. Object model advantages • Objects are loosely coupled so their implementation can be modified without affecting other objects. • The objects may reflect real-world entities. • OO implementation languages are widely used. • However, object interface changes may cause problems and complex entities may be hard to represent as objects.

  34. 11.3.2 Function-oriented pipelining(Data-flow) models • Functional transformations process their inputs to produce outputs • May be referred to as a pipe and filter model • Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems • Not really suitable for interactive systems

  35. Invoice processing system

  36. Pipeline model advantages • Supports transformation reuse. • Intuitive organization for stakeholder communication. • Easy to add new transformations. • Relatively simple to implement as either a concurrent or sequential system. • However, requires a common format for data transfer along the pipeline and difficult to support event-based interaction.

  37. 11.4 Control models • Are concerned with the control flow between sub-systems or how a system is decomposed into sub systems. • Two general approaches to control are centeralized control which mean one sub system has responsibility for control all sub systems, and event based control which means each sub system can respond to external event generated from other sub system.

  38. 11.4.1 Centralized control • Is one sub-system has overall responsibility for control and starts and stops other sub-systems • A control sub-system takes responsibility for managing the execution of other sub-systems

  39. Control model falls into two classes depending on whether the controlled sub systems execute sequentially or in parallel (concurrent):. Call-return model, top-down subroutine model where control starts at the top of a subroutine hierarchy and through calls passes to lower levels in the tree. Applicable to sequentialsystems. Manager model, applicable to concurrent systems. One system component controls the stopping, starting and co-ordination of other system processes. Can be implemented in sequential systems as in case statement

  40. Call-return model

  41. Real-time system control (concurrent model)

  42. 11.4.2 Event-driven systems • Event-based control, each sub-system can respond to externally generated events from other sub-systems or the system’s environment • Driven by externally generated events where the timing of the event is outside the control of the sub-systems which process the event.

  43. There are two event-driven control models:A- Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so and respond to it.B- Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processingOther event driven models include:-spreadsheets where changing the value of acell causes other cells to be modified. -production systems where acondition becoming true causes an action to be triggered.

  44. A- Broadcast model • Effective in integrating sub-systems on different computers in a network • Sub-systems register an interest in specific events, when these events occur, control is transferred to the sub-system which can handle the event. • Itdistinct from centralized model bycontrol policy is not embedded in the event and message handler. Sub-systems decide which events they require, and the event and message handler ensures that these events are sent to them. • However, sub-systems don’t know if or when an event will be handled

  45. Selective broadcasting

  46. B- Interrupt-driven systems • Used in real-time systems where fast response to an event is essential, (detecta possible crash and inflate the airbag quickly) • There are known interrupt types with a handler defined for each type • Each type of interrupt is associated with a memory location where the handler’s address is stored. When an interrupt is received, a hardware switch causes control to be transferred to its handler. • Allows fast response but complex to program and difficult to validate

  47. Interrupt-driven control

  48. 11.5Reference (Domain-specific) architectures • Architectural models which are specific to some application domain • Two types of domain-specific model • Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems • Reference models which are more abstract, idealized model. Provide a means of information about that class of system and of comparing different architectures • Generic models are usually bottom-up models; Reference models are top-down models

  49. Generic models • Compiler model is a well-known example although other models exist in more specialized application domains • Lexical analyzer • Symbol table • Syntax analyzer • Syntax tree • Semantic analyzer • Code generator • Generic compiler model may be organized according to different architectural models

  50. Compiler model

More Related