Teaching slides Chapter 5

Chapter 5: software high level design Contents Software engineering methodology considerations - Software architecture pattern : Monolithic architecture pattern : 2-tier architecture pattern : 3-tier architecture pattern : n-tier architecture pattern : Model view controller architecture pattern - Software designing technique consideration : Object oriented design & functional design Software design patterns User interface design patterns Business logic design patterns Database readymade components Programming language considerations Programming platform Software high level design

Chapter 5: software high level design Software engineering methodology considerations A software project experiences most impact from the chosen software engineering methodology. On Waterfall projects; complete software product is designed and built over the project. In contrast on Agile projects; a software product is built incrementally. On Waterfall projects; the project team has complete understanding as to what kind of software product they are building. But on Agile projects; the project team gets only a handful of software requirements at a time. So they never have a complete picture about the kind of software product they are building. From this perspective; it is advisable that they should be exposed to some high level software design aspects. Since a software product is built incrementally on Agile projects; software design and programming language selection should be done carefully so that it will allow a software product to be built incrementally.

Chapter 5: software high level design Software architecture patterns A software product can be small, mid sized or large. Some software products can be started as a small product but become large over a period of time. This is the case with software products which are built incrementally. A software product can either be built from scratch or can use some readymade templates. To create a software product from scratch will require lots of effort. It is better to use readymade templates as they allow large productivity gains. Architecture patterns are readymade templates which provide templates to create architecture for a software product. Architecture of a software product is the top level software design. For example, a software product may have a user interface, a business logic layer and a database. Architecture patterns define as to how these top layer software components should be arranged.

Chapter 5: software high level design Monolithic architecture patterns Some software products are small. They are also not expected to grow in future. In such a scenario, if we use an elaborate software architecture then it will be an overkill. Deploying a large scale architecture for small software product will also involve large costs. Thus it is better to have a simple architecture for such software products. Monolithic architecture patterns are simple and cheap to deploy. In such an architecture pattern, all the user interfaces, business logic, database etc. are not separated from each other. The drawback of this architecture pattern is that, if any of these layers need to grow then performance of the software product will be severely impacted. It is also not possible to scale them beyond a limit.

Chapter 5: software high level design Monolithic architecture patterns

Chapter 5: software high level design 2-tier architecture patterns Some software products are mid sized. They are also not expected to grow too much in future. In such a scenario, if we use an elaborate software architecture then it will be an overkill. Deploying a large scale architecture for mid sized software product will also involve large costs. Thus it is better to have a simpler architecture for such software products. 2-tier architecture patterns are not very complex and do not cost too much to deploy. In such an architecture pattern, all the user interfaces and business logic are not separate from each other. The database however is separate. So the database can be installed separately. The drawback of this architecture pattern is that, if any of the user interface or business logic layers need to grow in future then performance of the software product may be severely impacted. It is also not possible to scale them beyond a limit.

Chapter 5: software high level design 2-tier architecture patterns

Chapter 5: software high level design 3-tier architecture patterns Some software products are large sized. They may also grow in future. In such a scenario, we will definitely need to use an elaborate software architecture. Thus it is better to have an architecture pattern which will allow for scaling up for such a software product. 3-tier architecture patterns are complex and may cost money to deploy. In such an architecture pattern, all the user interfaces, business logic and database are separate from each other. If any of the layer needs to grow in future then it will never be a problem. Any of the 3 layers can be easily installed separately. The drawback of this architecture pattern is that, if the software product needs to be integrated with some other third party software product then it is not possible to do so.

Chapter 5: software high level design 3-tier architecture patterns

Chapter 5: software high level design n-tier architecture patterns Some software products are large sized. They may also need to be integrated with some other software product. In such a scenario, we will definitely need to use an elaborate software architecture. Thus it is better to have an architecture pattern which will allow for scaling as well integration with other software products. n-tier architecture patterns are complex and may cost money to deploy. In such an architecture pattern, all the user interfaces, business logic and database are separate from each other. If any of the layer needs to grow in future then it will never be a problem. Any of the 3 layers can be easily installed separately. At the same time, this architecture pattern will allow to be integrated with other software products.

Chapter 5: software high level design n-tier architecture patterns

Chapter 5: software high level design Model view controller architecture patterns Most software architectures are based on user interface – business logic layer direct interaction in form of input to a software product and output from the software product. in model view controller (MVC) architecture this direct connection between input and output is changed. Here a third component “controller” is placed between the “model” (business logic) and “view” (user interface). The controller component decides as to how and when to provide view against the processing done by the model component. MVC is used in many ways. In Java programming, servlets are used to provide 2 way communication between a Java class and a JSP file. Servlets also help in pooling requests for calls to classes and JSP pages and thus help in code reuse.

Chapter 5: software high level design Model view controller architecture patterns

Chapter 5: software high level design Software designing technique considerations The kind of software design selected for a project has far reaching impact. If functional design technique is chosen then scaling up or changing the design of the business logic can be difficult. For example JSP programming is a type of functional design. If we need to make changes then we will have to make changes at a lot of places as code reuse is minimal in functional programming. Functional programming is still needed for tasks like gluing user interfaces and database with the business logic layer. But implementing business logic should be done using object oriented design.

Chapter 5: software high level design Software designing technique considerations With object oriented design, scaling up or changing business logic design is lot easier and defect free. Since data is encapsulated; exposure to existing data structures is minimal and so chances of access to data is minimal and so wrong manipulation of data is mostly avoided. For example if all of our business logic is implemented in form of classes then any changes done in these classes will lead to lesser chances of defects. Since code reuse is much more in classes; we will need to make changes at less number of places.

Chapter 5: software high level design Software design patterns and components We have seen how architecture design patterns help in avoiding creating high level layers of a software product from scratch by using readymade templates. There are also software design patterns and readymade components which help in avoiding creating them from scratch. They ensure that productivity of the project team is high when they create all the low level designs for user interfaces, business logics and databases.

Chapter 5: software high level design User interface readymade components Almost all programming languages have created pre built packages which help in designing user interfaces. These packages have definitions and implementations for creating commonly used user elements like text boxes, labels, drop down lists, buttons, check boxes etc. The project team does not need to create these user elements from scratch. They just have to use the packages to draw and create everything needed for designing all user interfaces. In case a project team needs to create a custom user element then they may need to modify a standard user element by writing some code. In the next slide, you can see a standard rectangle is being changed into a custom shape

Chapter 5: software high level design User interface readymade components

Chapter 5: software high level design Business logic design patterns Business logic design and implementation is the most labor intensive work on any software project. For this reason many programming language vendors and researchers have created many design patterns which can be used to reduce amount of code to be written to implement any business logic. Software designers need to create a hierarchy of classes or objects from a parent class or object to implement a business logic. For this need, a set of design patterns have been created which are categorized as creational design patterns. When behavior of an object needs to be changed dynamically to implement a business logic then behavioral design patterns are used. Structural design patterns are used when classes with non matching interfaces need to be integrated at runtime.

Chapter 5: software high level design Creational design patterns One of the commonly used creational design pattern is the abstract factory design pattern. Here a parent class may define a structure. The child classes can implement this structure differently to create slightly different functionality. This type of creating child classes with different structures can be done at many levels and so a large number of slightly different things can be modeled in a software product. For example, we can model many types of laptops from a single class by creating child classes with different implementation of the structure defined in the parent class. We can further differentiate laptops based on different models further down the hierarchy by creating child classes with different implementations of the same structures. In the next slide this example of abstract factory design pattern is depicted.

Chapter 5: software high level design Abstract factory design pattern

Chapter 5: software high level design Creational design patterns One more example of creational design pattern is the builder design pattern. Here a parent class may be defined to create a dynamic menu structure. The child classes can implement this menu structure differently to create different menus. For example, we can model a dynamic menu structure so that each menu choice may have different menus. Similarly we can model menus for a restaurant. Based on a specific menu, the ingredients needed will be different. In the next slide this example of builder design pattern is depicted.

Chapter 5: software high level design Abstract factory design pattern

Chapter 5: software high level design Structural design patterns Structural design patterns are used when we need to integrate classes which have non matching interfaces. One example of structural design pattern is the Façade design pattern. Here when a class from a group of classes is tried to be called at runtime then depending on a specific condition one specific class from the group of classes will be called. This happens because a common class which acts as a façade is always called first. Later the façade delegates the call to the right class. For example, we can model a software product which has many versions available. Depending on the type of user request, a particular version of the software product will be invoked and will be opened for the user. In the next slide, example of a façade design pattern is depicted.

Chapter 5: software high level design Façade design pattern

Chapter 5: software high level design Behavioral design patterns Behavioral design patterns are used when we need to change behavior of an object at runtime. One example of behavioral design pattern is the chain of responsibility design pattern. Here an object will display a different behavior at runtime if some conditions get changed. For example, at any ATM, request for money withdrawal is fulfilled by dispensing currency notes of different denominations. If currency notes of a particular denominations have exhausted then it is still possible to fulfill a money withdrawal request by dispensing currency notes of other available denominations. This functionality is achieved by the algorithm computing the same amount of money using an alternative method. In the next slide, example of a chain of responsibility design pattern is depicted.

Chapter 5: software high level design Behavioral design pattern

Chapter 5: software high level design Behavioral design patterns One example of behavioral design patterns is the command design pattern. Command design pattern is used when we need for an object to wait for a command and only then it will execute. For example, at any warehouse, request for order fulfillment is an ongoing activity. Many fulfillment orders keep coming and based on the available goods in the warehouse they are fulfilled. If a fulfillment order was received but goods were not available then the order will be kept waiting till goods become available. At the same time orders received later can be processed earlier than the previous order if goods are available. This functionality is achieved by the algorithm computing the fulfillment process. In the next slide, example of a command design pattern is depicted.

Chapter 5: software high level design Behavioral design pattern

Chapter 5: software high level design Database readymade components Databases are special types of software products. Relational databases are mostly used for creating and storing permanent data which are used by most software products. Relational databases use proprietary technology. Most database vendors do not expose any interfaces through which they can be modified. However all of the relational databases allow to create structures like database tables, schemas, indexes, sequences, primary and foreign keys etc. so that creation and management of permanent data can be done comfortably.

Chapter 5: software high level design Programming language considerations Programming language for the project must be selected carefully. Different programming languages are designed to provide efficient code writing for specific purposes. For example, Matlab programming language is designed so that mathematical and scientific programming can be done with very high productivity gains as it has many built in functions for doing scientific and mathematical programming with less amount of code writing.

Chapter 5: software high level design Programming language considerations Smart mobile phones and handheld devices have evolved extensively in the last decade. People use them for many purposes. So many software vendors are creating software products which run exclusively on these devices. These devices have very small user interfaces as well as processing power of these devices are much less compared to personal computers. At the same time, different makers of these devices use different operating systems. For example, Apple uses its own proprietary operating system. So when a software product is being developed for mobile devices then these factors must be considered for choosing the appropriate programming language.

Chapter 5: software high level design Programming language considerations World Wide Web (WWW) has become the preferred computing platform over the last 2 decades. Cloud computing is providing new choices for people and is impacting their lifestyles. Web based software products are being developed for many purposes and a large number of software vendors are involved in creating software products which run on the internet. Some characteristics of www include stateless communication and exposure to security threats from hacking by unscrupulous people. Programming languages which can overcome these challenges should be preferred while creating web based software products. Some of the suitable programming languages and supporting technologies for creating web based software products include Java, C#, JavaScript, HTML, Java Server Pages etc.

Chapter 5: software high level design Programming platforms and tools A suitable programming platform or Integrated Development Environment (IDE) must be chosen for a project so that it will allow to write code productively and without any hassles. For example, Eclipse IDE is a good platform to write Java programs as it has built is support for integrating application servers like Tomcat, databases like Oracle, MySQL etc. and many supporting tools. It also has good features like text editors, graphical editors, automated refactoring tools etc.

Chapter 5: software high level design On Agile projects, customer provides only a bunch of user stories at a time to the project team. Thus the project team never gets the big picture about the kind of software product they are building. This factor also does not help the project team to choose appropriate software designing and programming platform and programming language. To overcome this handicap, customers also provide a long story at the beginning of the project. This long story describes as to what the proposed software product will do and how users can use it. This long story is known as an epic.