Analysis Modeling, Design Concepts, and Architectural Design - Assignment Example

IT210 Assignment 4: Analysis Modeling, Design Concepts, and Architectural Design No Name Date Analysis Modeling, Design Concepts, and Architectural Design Software design and architecture requires understanding of Entity Relationship Diagram, Class Diagram, relationship between design and programming, rationality behind modular programming, and relation between the concepts of portability and coupling. These underlying concepts of software design assist in building robust architecture, connecting structural elements for satisfying clients’ needs. Example of Linux operating system explains benefits of layered architecture. The case study of the automated insulin delivery system requirements further establishes a relationship between different elements of software design to develop a holistic view of the concepts in real-life scenario. Difference between ER and Class Diagram ER diagrams reflect the relationship between entities and associated attributes in the data model, whereas class diagram reflects the relationship between classes and their associated attributes of the proposed system handling real-life business scenario. ER diagram defines underlying business logic in tables of database and their relation, whereas class diagram business process of objects into the real-world (Pressman, 2005). ER diagram provides logical representation of tables in the data model and their relationship. Class diagram defines the structural element of the system and their process to create software. If a Software Design is not a Program (and it isn’t), then what is it? Software design is not a program, but it defines high level abstraction or pieces of logic for satisfying business requirement from a client into creation and delivery of software before even coding starts (Pressman, 2005). Software design creates a plan from inception phase of software till final piece of software in alignment with desired outcomes expected from client. Software design needs to utilize all information available regarding business objective and technological requirement to make successful creation of software. Programming is an important aspect of software that requires data synchronization through communication between technical and business players to make information system successful. Why not have a Large Module that does Many Things? Different modules defining different functions of the program is a preferable option in comparison to putting whole logic into one large module because of maintenance, readability, debugging, and the ease of writing. Modular programming provides independence of developing and testing irrespective of what other different pieces of logic are doing. It also makes the main part of code easier to understand and maintain as only simple function and procedure is called instead of a large program written in the main section of the code (Pressman, 2005). Modules also enhance the reuse of code, which saves effort of programming. If standard mathematical functions such as mean, mode, median, etc., are needed in a different module, they can be simply invoked instead of rewriting the code again and again. How are the Concepts of Coupling and Software Portability Related? The law of Demeter suggests passing the message between neighbouring classes to maintain low coupling. Software requires collaboration between classes to complete the logic of business classes. However, if software design provides highly coupled model, it will become painful to develop, test, and maintain the code in the long term. High coupling affect software portability that remains dependent on database, compiler, or other associated technological platforms (Pressman, 2005). In case a program considers implementation of a graphic illustration associated with a particular terminal, then it will affect software portability, especially if the code requires extensive modification to work on other system that is not attached to the particular terminal. Explain the Purpose of Software Architecture and How it Relates to Design The purpose of software architecture is to provide underlying support through structural elements and association to identify and assign function through interfaces. Ulrich and Stephen (2004) found that architectures need to consider different components of the system and sub-system that can support the development of program, satisfying current and future requirements with options of extension in reasonable expenses. Loose coupling, seamless interfaces, and platform for simple and interrelated pieces are characteristics of robust software architecture (Ulrich & Stephen, 2004). Software architecture is not a low-level design that takes care of the data model, although it uses them for defining signature of interfaces. Although it applies hardware configuration system for assessing performance and reliability of software, software and hardware architecture is different. Benefits of Layered Architecture based on Example of Linux Operating System Linux operating system has a kernel at the core of operating system that provides access to the internal resources of hardware such as memory, CPU using scheduler and peripherals (Jones, 2005). Linux OS provides support to various types of shell that allows the user to access the kernel. Shell acts as a mediator to be interpretive of commands for loading applications and executing programs for providing desired outcomes to end users. Applications are the top layer of the operating system architecture that constitutes a major proportion of Linux OS. The layered architecture of Linux OS improves performance, scalability, and fault tolerance. These application designs enable Linux OS to support windows, integrated development environment, and web based programs such as e-mail, browsing, etc., in a secured way (Jones, 2005). Figure 1: Linux Operating System (Jones, 2005) Hardware drivers provide access to port, display, and network adapters that reside into the kernel. Analysis of the Automated Insulin Delivery System Requirements Technological revolution in micro sensors made it possible to design an automated insulin delivery system through attachment to diabetic patients. These sensors can measure the sugar level of patients applying software installed in sensors by assessing blood parameters. The miniature insulin pump system can receive the signal from the software controlled measuring sensor to inject insulin in the blood through a permanently attached needle. Blood sugar sensor can take a sample to analyze it on the basis of parameters required for checking sugar level. Software can act as insulin controller to compute the requirement of insulin based on the level of sugar in the blood. The insulin delivery controller will further take the information of insulin requirement to pass it to insulin pump through a set of commands. Insulin pump will inject required amount of insulin into the blood of diabetics. Figure 2: Model of the Insulin Pump Above hardware design explains the basic model of the insulin pump in which blood sensor captures electric current in relation to the sugar level in the blood and generates corresponding pulse to the controller for injecting units of insulin. If patients require 5 units of insulin, it will display 5 electric pulses to inject that amount of insulin. Sequence of commands explained in the previous paragraph provides a set of steps followed in software controlled system to convert information of the blood sugar level into the requirement of insulin that needs to be injected into the blood. The life-critical software system can put the patient into emergency condition if it does not raise an alarm because of either too high or too low level of sugar in case of empty insulin reservoir or it fails to operate altogether. A critical necessity of the Automated Insulin Delivery System is as follows: 1. Automated Insulin Delivery System should inject required amount of insulin depending on the sugar level of blood. 2. The system should remain available The system will calculate adequate dosage of insulin and safety limits of blood sugar level. System will also retain previous two readings of blood sugar to compute rate of change of sugar level in the blood along with current reading from the sensor. System will compute insulin dose from these readings. If sugar level is in the normal range or if the rate of increment in sugar level is decreasing or sugar level is decreasing, then computed insulin dose will be zero. But if the rate of increment in sugar level is increasing or sugar level is increasing, computed does will be rounded figure of difference current and previous reading. If rounded figure becomes zero, then minimum dose will be applied. If insulin reservoir does not contain a minimum dose of insulin, then it should raise an alarm. The current reading will be set as the previous reading once pump system delivers the insulin. References Jones, M. T. (2005). Gnu/Linux Application Programming (1st Ed). Charles River Media. Pressman, Roger S (2005). Software Engineering: A Practitioners Approach (6th ed.). Boston, Mass: McGraw-Hill. Ulrich, K. and Stephen, E. (2004). Product Design and Development. McGraw-Hill. Read More