Introduction to Software Design (SEng3132) PDF

Chapter one lecture one Introduction to software design Software Architecture and Design (SEng3132) By Destaye A. 1 1  Software architecture, definition Software architecture refers to the fu...

Chapter one lecture one Introduction to software design Software Architecture and Design (SEng3132) By Destaye A. 1 1  Software architecture, definition Software architecture refers to the fundamental structures of a software system or product that developers use as an overarching visual guide when planning for and building software, Software architecture is a conceptual framework defining the system's high-level structure, components and relationships It serves as a blueprint for both the system and the project developing, it providing a foundation for both technical and organizational decisions.  Con… The architecture of a software system defines the system in terms of computational components and interactions among those components. (from Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996.) Component-based architecture focuses on the decomposition of the design into individual functional or logical components that represent well-defined,  Con… Software architecture is, simply the organization of a system. This organization includes all components, how they interact with each other, The behavior and structure of the software impact significant decisions, so they need to be appropriately built for the best possible software results.  Key Components of Software Architecture Components: The individual parts of the system, which can be modules, classes, services etc. Each component encapsulates specific functionality. Relationships: How components interact with each other including data flow, control flow and communication protocols. Patterns: Common architectural patterns (e.g. MVC, micro services, layered architecture etc. ) that provide templates for solving recurring design problems. Constraints: Rules and limitations that affect the architecture such as regulatory compliance performance requirements or technological restrictions. Quality Attributes: Non-functional requirements that define how the system performs under certain conditions including scalability, reliability, maintainability and security  ARC…in SWE Software architecture in software engineering helps to expose the structure of a system while hiding some implementation details. Architecture focuses on relationships and how the elements and components interact with each other, as does software engineering. Software Architecture has role to reduce software project failure rate by: ✓ Tackling complexity of software development and ✓ Enabling achievement of quality requirements  Con… Architecture is a Set of Software Structures: 1.Modules – divides up system functionality assigned specific computational responsibilities, are the basis of work assignments for programming team 2. Component-and-connector (C&C) dynamic structures how elements interact with each other at runtime processes, objects, clients, servers, and data store pathways of interaction, such as communication links and protocols, information flows, and access to shared storage.  Con… 3. Allocation structures Allocation structures embody decisions as to how the system will relate to non software structures in its environment (such as CPUs, file systems, networks, development teams, etc.) mapping from software structures to the system’s organizational, developmental, installation, and execution environments Deployment, Implementation  Architecture vs. Design Software architecture: is a plan that gives enough detail to produce a software design. Architecture constrains designs to achieve an organization's business and technology strategy. Software architecture places big-picture constraints on the design to ensure that it aligns with the business and technology strategy of an organization.  Cont.. Software design: It is the process of determining how a system will perform its intended functions, Software design is defined as a process of problem solving and planning for a software solution. The first step for software design is to define the aim and characteristics of the software. This includes specifications of services, components, integrations, data models and algorithms.  Con… Software design is a process to transform user requirements into some suitable form which helps the programmer in software coding and implementation, how the software system is decomposed and organized into components and modules. It defines the relationship between these modules.  Goals of Software Architecture Expose the structure of the system, but hide its implementation details. Realize all the use-cases and scenarios. Try to address the requirements of various stakeholders. Handle both functional and quality requirements. Reduce the goal of ownership and improve the organization’s market position. Improve quality and functionality offered by the system. Improve external confidence in either the organization or system. Software Arc VS software Design The Many Contexts of Software Architecture Business Context Architectures serve some business purposes Architects need to understand who the vested organizations are and what their goals are Many of these goals will have a profound influence on the architecture. lowering costs might be realized by asking employees to work from home, or turn the office thermostats down in the winter, or using less paper in the printers. Professional Context You will perform many duties beyond directly producing an architecture. Architects need more than just technical skills. Explaining, diplomatic, negotiation, and communication skills. Architects need up-to-date knowledge: You will need to know about (for example) patterns, or database platforms, or web services standards.  Stakeholders a person or organization that has rights, shares, claims, or interests concerning the system or its properties meeting their needs and expectations. To put it more simply, the interests of stakeholders have some influence on the software project  Why Is Software Architecture Important? Predicting system qualities Predicting system qualities is possible as we know that certain kinds of architectural decisions lead to certain QAs in a system, The earlier you can find a problem in your design, the cheaper, easier, and less disruptive it will be to fix ,  Con … Enhancing communication among stakeholders Every stakeholder has different concerns; Architecture can be used as a basis for mutual understanding, negotiation and communication among stakeholders. Abstract Architecture can be understood by most nontechnical people,  Con.. Improving cost and schedule estimates Architect helps to create cost and schedule estimates early in the project life cycle Top-down estimates (created by the architect and project manager) are useful for setting goals and apportioning budgets. Bottom-up cost estimations are more accurate than purely top-down system knowledge (created by the developers).  Con… Basis for Training The architecture can serve as the first introduction to the system for new project members. Module views show the structure C&C - explaining how the system work.  Software quality The notion of quality is central in software architecting: software architecture is devised to gain insight in the qualities of a system at the earliest possible stage. Qualities are two types. Static quality attributes Reflect the structure of a system and organization, directly related to architecture, design, and source code. They are invisible to end- user, but affect the development and maintenance cost, e.g.: modularity, testability, maintainability, portability, etc. Dynamic Quality Attributes Reflect the behavior of the system during its execution. They are directly related to system’s architecture, design, source code, configuration, deployment parameters, environment, and platform. They are visible to the end-user and exist at runtime, e.g. performance, security, functionality, throughput, robustness, scalability, etc.  Role of Software Architect Excellent software engineering skills Lead technical development team by example Solve the hard problems Understand impact of decisions Defend architectural design decisions Know and understand relevant technology Track technology development 21 21  Design Definition: – Design is a problem-solving process whose objective is to find and describe a way: To implement the system’s functional requirements while respecting the constraints imposed by the quality and budget.” 22  Design as a series of decisions A designer is faced with a series of design issues – Each issue normally has several alternative solutions: design options. – The designer makes a design decision to resolve each issue. This process involves choosing the best option from among the alternatives. Making decisions-To make each design decision, the software engineer uses: Knowledge of the requirements the design as created the technology available software design principles 23  Objective of software design Software design is both a process and a model. The design process is a sequence of steps that enable the designer to describe all aspects of the software to be built. The objectives are to: – Identify different types of software, based on the usage. – Show differences between design and coding. – Illustrate some basic design concepts. – See how to design for testability and maintainability. – Introduce some formal design notations.  Software Design Activities These activities can vary depending on the type of the system/software needs to be developed. There are four main activities that may be part of the design process, these are: 1. Architectural design: It defines the overall structure of the system, the main components and their relationships. 2. Database design: The system data structures are designed and their representation in a database is defined. This depends on whether an existing database is to be reused or a new database to be created.  Cont.. 2. Interface design: It defines the interfaces between these components. The interface specification must be clear. Therefore, a component can be used without having to know it’s implemented. Once the interface specification are agreed, the components can be designed and developed concurrently. 4. Component design: Take each component and design how it will operate, with the specific design left to the programmer, or a list of changes to be made to a reusable component.  Principles Leading to Good Design Overall goals of good design: – Increasing profit by reducing cost – Ensuring that we actually conform with the requirements – Accelerating development – Increasing qualities such as Changeability Extensibility Reusability 27  Changeability Existing requirements change and new ones are added. To reduce maintenance costs and the workload involved in changing an application, it is important to prepare its architecture for modification and evolution. Two reasons why software ages: Lack of movement-software ages if it is not frequently updated. Ignorant surgery-changes made by people who do not understand the original design, gradually destroy the architecture. 28  Extensibility This focuses on the extension of a software system with new features, as well as the replacement of components with improved versions and the removal of unwanted or unnecessary features and components. To achieve extensibility a software system requires loosely-coupled components. 29  Reusability It promises a reduction of both cost and development time for software systems, as well as better software quality. Reusability has two major aspects-software development with reuse and software development for reuse: Software development with reuse means reusing existing components and results from previous projects or commercial libraries or code components. Software development for reuse focuses on producing components that are potentially reusable in future projects as part of the current software development. 30  Design Principle 1: Divide and conquer Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things – Separate people can work on each part. – An individual software engineer can specialize. – Each individual component is smaller, and therefore easier to understand. – Parts can be replaced or changed without having to replace or extensively change other parts. 31  dividing a software system – A distributed system is divided up into clients and servers – A system is divided up into subsystems – A subsystem can be divided up into one or more packages – A package is divided up into classes – A class is divided up into methods 32  Con… Coupling and Cohesion are two key concepts in software engineering that are used to measure the quality of a software system’s design. Both are important factors in determining the maintainability, scalability, and reliability of a software system. High coupling and low cohesion can make a system difficult to change and test, while low coupling and high cohesion make a system easier to maintain and improve.  Design Principle 2: Increase cohesion where possible Cohesion:- is a measure of the degree to which the elements of the module are functionally related. Measure of how well module fits together. A component should implement a single logical function or single logical entity. A subsystem or module has high cohesion if it keeps together things that are related to each other, and keeps out other things – This makes the system as a whole easier to understand and change – Type of cohesion: Functional, Layer, Communicational, Sequential Cohesion, Temporal Cohesion, Procedural cohesion, Logical cohesion 34  Functional cohesion This is achieved when all the code that computes a particular result is kept together - and everything else is kept out – i.e. when a module only performs a single computation, and returns a result, without having side-effects. – Benefits to the system: Easier to understand More reusable Easier to replace – Modules that update a database, create a new file or interact with the user are not functionally cohesive 35  Layer (Sequential) cohesion All the facilities for providing or accessing a set of related services are kept together, and everything else is kept out – The layers should form a hierarchy Higher layers can access services of lower layers, Lower layers do not access higher layers – The set of procedures through which a layer provides its services is the application programming interface (API) – You can replace a layer without having any impact on the other layers You just replicate the API 36 Example of the use of layers 37  Communicational cohesion All the methods that access or manipulate certain data are kept together (e.g. in the same class) - and everything else is kept out – A class would have good communicational cohesion if all the system’s facilities for storing and manipulating its data are contained in this class. – Main advantage: When you need to make changes to the data, you find all the code in one place – Example- Student Manager class (insert, update, delete, search etc.) 38  Utility cohesion When related utilities which cannot be logically placed in other cohesive units are kept together – A utility is a procedure or class that has wide applicability to many different subsystems and is designed to be reusable. Procedural Cohesion Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA. 39  Design Principle 3: Reduce coupling where possible Coupling:- The degree of dependence such as the amount of interactions among components Coupling occurs when there are interdependencies between one module and another – When interdependencies exist, changes in one place will require changes somewhere else. – A network of interdependencies makes it hard to see at a glance how some component works. – Type of coupling: Common, Control, Data, Stamp, External and content coupling 40  Data Coupling If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent to each other and communicating through data.  Common coupling The modules have shared data such as global data structures. Occurs whenever you use a global variable – All the components using the global variable become coupled to each other – can be acceptable for creating global variables that represent system-wide default values – The best way is declare all the global variables in an interface and use them through interface – The Singleton pattern provides encapsulated global access to an object 42  Control coupling If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior, and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument Occurs when one procedure calls another that explicitly controls what the second procedure does – To make a change you have to change both the calling and called method – The use of polymorphic operations is normally the best way to avoid control coupling – One way to reduce the control coupling could be to have a look-up table 43  Routine call coupling Occurs when one routine (or method in an object oriented system) calls another – The routines are coupled because they depend on each other’s behaviour – Routine call coupling is always present in any system. – If you repetitively use a sequence of two or more methods to compute something 44  External Coupling In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc. Design Principle 4: Keep the level of abstraction as high as possible Ensure that your designs allow you to hide or defer consideration of details, thus reducing complexity – A good abstraction is said to provide information hiding – Abstractions allow you to understand the essence of a subsystem without having to know unnecessary details 46  Abstraction and classes Classes are data abstractions that contain procedural abstractions – Abstraction is increased by defining all variables as private. – The fewer public methods in a class, the better the abstraction – abstract classes and interfaces increase the level of abstraction 47  Design Principle 5: Increase reusability where possible (for reuse) Design the various aspects of your system so that they can be used again in other contexts – Generalize your design as much as possible 48 Design Principle 6: Reuse existing designs and code where possible(with reuse) Design with reuse is complementary to design for reusability – Actively reusing designs or code allows you to take advantage of the investment you or others have made in reusable components. 49  Design Principle 7: Design for flexibility Actively anticipate changes that a design may have to undergo in the future, and prepare for them – Reduce coupling and increase cohesion – Create abstractions – Do not hard-code anything – Use reusable code and make code reusable 50  Design Principle 8: Anticipate obsolescence Plan for changes in the technology or environment so the software will continue to run or can be easily changed – Avoid using early releases of technology – Avoid using software libraries that are specific to particular environments – Use standard languages and technologies that are supported by multiple vendors 51  Design Principle 9: Design for Portability Have the software run on as many platforms as possible – Avoid the use of facilities that are specific to one particular environment – E.g. a library only available in Microsoft Windows 52  Design Principle 10: Design for Testability Take steps to make testing easier – Design a program to automatically test the software Ensure that all the functionality of the code can be driven by an external program, bypassing a graphical user interface. 53  User Interface Design User Interface Design is the discipline of designing software interfaces for devices, ideally with a focus on maximizing efficiency, responsiveness to foster a good user experience. UI design is typically employed for products or services that require interaction for the user to get what they need from the experience. The interface should allow a user to perform any required tasks to complete the function of the product or service. An interface is a point of interaction between the user and the hardware and/or software they are using. UI design is the skill employed to visualize the interface used to complete the task it is designed for. Good UI design facilitates making the completion of tasks as frictionless as possible and increasing usability.  Cont.. UI can be graphical, text-based, audio-video based, depending upon the underlying hardware and software combination. UI can be hardware or software or a combination of both. The software becomes more popular if its user interface is: – Attractive – Simple to use – Responsive in short time – Clear to understand – Consistent on all interfacing screens