More Related Content
Similar to Architecture Design in Software Engineering (20)
Architecture Design in Software Engineering
- 2. Software Design • Design activity begins when SRS document for software is available • Design is the first step towards solution domain from problem domain • Design can accurately translate customer’s requirement into a finished software product • Software Design is the practice of taking a specification of externally observable behavior and adding details needed for actual computer system implementation, including human interaction, task management and data management skills.
- 3. Importance of Design • System model • Help you understand requirement better • Prevents redundancy and increases reusability • Points out the risk of which you have no idea
- 5. Software Architecture • The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. • The output of this design process is a description of the software architecture. • Software architecture is he process of defining software methods, functions, objects and the overall structure and interaction of your code so that the resulting functionality will satisfy the user’s requirements
- 6. Architecture Design • An early stage of the system design process. • Identifies the sub-system from large systems • Concerned with understanding how a system should be organized • It involves identifying major system components and their communications. • Represents the link between specification and design processes. • Often carried out in parallel with some specification activities.
- 7. Components of Architecture Design 1. Architectural design decisions 2. System organisation 3. Decomposition styles 4. Control styles
- 8. Architecture Design Decision • Is there a generic application architecture that can be used? • How will the system be distributed? • What architectural styles are appropriate? • What approach will be used to structure the system? • How will the system be decomposed into modules? • What control strategy should be used? • How will the architectural design be evaluated? • How should the architecture be documented?
- 9. 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 layered style.
- 10. The Repository Model • Sub-systems making up a system must exchange information so that they work together effectively. • 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. • Suited for applications where data is generated by one sub-system and used by another.
- 11. • The components do not interact on their own, only through the central reposition • All the components in the system compromise for the exchange of data • New components are difficult to integrate Project Management Software
- 12. Application • When large volume of information is generated and has to be stored for long time • When data security is of higher importance • When the control of the system needs to be central
- 13. Advantages • Independent of component as they need not know their existence • Easy to accommodate change in a component • All information are centrally managed and easily available • Sub-systems need not be concerned with how data is produced Centralised management e.g. backup, security, etc. Disadvantages • Any problem in the central reposition affect whole system • Communication issues are likely to arise since compromise in inevitable • Process distribution is a challenge • Data evolution is difficult and expensive;
- 14. Client-Server Model • A system model where the system is organized as a set of services and associated servers and clients that access & use the services. • i.e. Distributed system model which shows how data and processing is distributed across a range of components. • The major components of this model are: 1. A set of servers that offer services to other subsystems such as printing, data management, etc. 2. A set of clients that call on services offered by the servers. 3. A network that allows clients to access these services.
- 15. • Mainly, client-server architecture considered as distributed system • But the logical model can be implemented on single computer • It emphasizes on separation and independence since change in server or client do not affect each other • Application: • When same service has to be provide to different clients in different location
- 16. • Clients may have to know the names of the available servers & the services they provide • However, servers need not know either the identity of clients and their number. • Clients accesses the service from remote procedural call using request reply protocol such as http. Youtube Architecture
- 17. Advantages • Distribution of data is straightforward; • Makes effective use of networked systems. May require cheaper hardware; • Easy to add new servers or upgrade existing servers. Disadvantages • No shared data model so sub-systems use different data organisation. 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.
- 18. Abstract Machine (Layered) Model • Used to model the interfacing of sub-systems. • Organises the system into a set of layers (or abstract machines) each of which provide a set of services. • Each layer can be thought of as an abstract machine whose machine language is defined by the services provided by the layer beneath it. • This language used is to implement the next level of abstract machine. • Supports the incremental development of sub-systems in different layers.
- 19. • i.e. it supports development of layers separately and independently • When a layer interface changes, only the adjacent layer is affected. • The components are changeable and portable since developed in independent approach
- 20. Application • When tier needs to be created to service the model. • When the key factor to consider is security. • When information has to be passes over a network.
- 21. Advantages • It allows the replacement of a entire faulty layer. • It provides robustness and stability • Independent portable of components is possible. • The model is flexible, scalable and maintainable Disadvantages • It is practically difficult to achieve separation between layers. • Performance can be of issue. • Data overhead and processing delay due to multiple layers • Risk of data being lost in upper layers
- 22. Modular Decomposition • Decomposition of sub-systems into modules or process modules is called modular decomposition. • There are two main strategies that one can use while decomposing subsystem into modules. 1. Function oriented Pipelining • A Function oriented pipelining (or data-flow model) where the system is decomposed into functional modules which transform inputs to outputs. 2. Object Oriented Decomposition • An Object oriented model where the system is decomposed into interacting object
- 23. Differences-Sub-system 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 normally be considered as a separate system. • To produce its output it requires other’s input
- 24. Function Oriented Pipelining • System is decomposed into set of interacting units which has clearly defined function. • Functional transformations process their inputs to produce outputs. • May be referred to as a pipe and filter model (as in UNIX shell). • When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. • It only views system as black-box that performs high level function. • It follows top down approach mainly used for computation sensitive application • Not really suitable for interactive systems.
- 25. Invoice Processing System • An Invoice processing system has issued invoices to customers • Once a week, payments that have been made reconciled with the invoices • For invoices that have been paid, a receipt is issued. • For invoices that have not been paid within the allowed payment time, reminder is issued. • This model is only the part of invoice processing system
- 26. 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.
- 27. Object Oriented Decomposition • Structure the system into a set of loosely coupled objects with well-defined interfaces. • Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. • Objects are defined which collaborate to fulfill the requirements. • When implemented, objects are created from these classes and some control model used to coordinate object operations.
- 28. Invoice Processing System • This system can issue invoices to customers • receive payments & issue receipts for these payments, reminders for unpaid invoices • Object classes have names and a set of associated attributes • Operations, if any are defined in the lower part of the rectangle representing the object. • Dashed arrows indicate that an object uses the attributes or services provided by another object.
- 29. Advantages • Objects are loosely coupled so their implementation can be modified without affecting other objects. • The objects may reflect real-world entities because of which objects can be reused. • OO implementation languages are widely used. • However, object interface changes may cause problems and complex entities(abstract) may be hard to represent as objects.
- 30. Control Styles • Control styles offer a mechanism to regulate the components or routine in the software • It allows one function to access other sub-function to carry out the task • Is concerned with the control flow between sub-systems. Distinct from the system decomposition model. 1. Centralised control One sub-system has overall responsibility for control and starts and stops other sub- systems. 2. Event-based control Each sub-system can respond to externally generated events from other sub-systems or the system’s environment.
- 31. Centralized Control • Here, one subsystem is designated as the system controller & has responsibility for managing the execution of other sub systems. • Centralized control models fall into two classes, depending on weather the controlled sub-system execute sequentially or in parallel 1. Call return model: Here the control is passed down the hierarchy and the result is passed to the calling function or object 2. Manager model: Here one component controls the execution of other components.
- 32. Call Return Model • Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems. • This model may be used at the module level to control functions and objects. • Strength-It is relatively simple to analyze control flows & work out how the system will respond to particular inputs. • Weakness- exceptions to normal operation are awkward to handle.
- 33. • In fig. the main program call routines 1,2 &3; Routine 1 can call Routine 1.1 & 1.2;Routine 3 can call Routines 3.1 & 3.2; & so on. • Here, control passes from a higher-level routine in the hierarchy to the lower level • Then it returns to a point where the routine was called • The currently executing subroutine has responsibility to control & can either call other routines or return control to its parents. • It is poor programming style to return to some other point in the program.
- 34. Manager Model • One system component controls the stopping, starting and coordination of other system processes. • Can be implemented in sequential systems as a case statement. • Applicable to concurrent systems.
- 35. • In fig., shows the centralized management model of control for a concurrent system. • This model is often used in “soft” real-time systems which do not have very tight time constraints. • The central controller manages the execution of set of processes associated with sensors and actuators • The system controller decides when processes should be started or stop depending on system state variables. • It checks whether other processes have produced information to be processed or pass the information to them for processing.
- 36. Event Driven Control • Event driven control models are driven by externally generated events where the timing of the event is outside the control of the process that handles that event. • Other event driven models include spreadsheets and production systems. • Two principal event-driven models 1. Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so; 2. Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing.
- 37. Broadcast Model • Here an event is broadcasted to all sub- system • Any sub-system that has been programmed to handle can respond to it. • Here, a sub-system has to register an interest in specific events. • When these events occur, control is transferred to that sub-system which can handle it. • Sub-system decide which event they require, & the event of interest to them.
- 38. Interrupt Driven Model • Used in real-time systems where fast response to an event is essential. • There are known interrupt types with a handler defined for each type. • Each type is associated with a memory location and a hardware switch causes transfer to its handler. • Allows fast response but complex to program and difficult to validate.
- 39. Interrupt Driven Model • In fig., there are known number of interrupt types with the handler defined for each type. • Each interrupt is associated with a memory location where its handler’s address is stored. • When an interrupt of a particular type is received, h/w switch causes control to be transferred immediately to its handler. • This interrupt handler may then start or stop other processes in response to the event signaled by the interrupt.
- 40. Reference Architecture • Distributed Object Architecture • Multi-processor Architecture • Inter-organizational Distributed Computing