Posts

Showing posts from October, 2019

HW22: Chapter 21

21.4. Explain why an object-oriented approach to software development may not be suitable for real-time systems. For an object-oriented approach to software development, top-down design processes are typically used. This means creating a high-level model and decomposing down. This development model is not ideal for real-time system design due to several factors. First, real-time systems typically have different constraints that have a greater impact on system performance. Physical limitations for an embedded system may affect power, space, size, weight, etc., which in turn has an impact on the processing power available, memory size, etc. While these constraints may exist in other non-real time systems, the limitations are more extreme in real-time systems. There is also a necessity for direct hardware interaction that object-oriented design hides information about data and accessing the values has a performance cost that is often too high to permit its use in real-time systems. I...

HW 21: Team Progress I

Team Progress Team Lamp has come together quite well on the project. Each member has been upfront about deficiencies but also indicated a willingness to work toward completing each deliverable on time. I'm going to give a brief overview of our progress and some of the challenges we have faced thus far.  The goal of our project was to find an open-source project and use that project to create a testing framework to test a small portion of the project. We chose Glucosio, an android project designed to help people manage their blood sugar levels.  Building the Project Our first real hurdle came shortly after this when we had quite a bit of trouble getting the project to build. It had been dormant for about four years and this point and it had no real documentation about installation or development. A contributing factor in this was the fact that no one on our team had experience with Android Studio or, I'm sad to admit, experience with building a project period. Becau...

HW:20 Chapter 20

20.10. You work for a software company that has developed a system that provides information about consumers and that is used within a SoS by a number of other retail businesses. They pay you for the services used. Discuss the ethics of changing the system interfaces without notice to coerce users into paying higher charges. Consider this question from the point of view of the company's employees, customers, and shareholders. The answer to this question depends largely on the relationship between the various SoS managers/companies was established and maintained. Companies choose to use systems of systems because it is to their benefit. They can rely on another entity to create a product that they can use in their own product and by doing so save on cost. Typically, these companies are not choosing to use the system of systems for some altruistic purpose but instead to make their businesses more profitable. This is why it is important for businesses using systems of systems softw...

HW19: Chapter 19

19.3. Why is it impossible to infer the emergent properties of a complex system from the properties of the system components. Emergent properties are properties of the system as a whole. These properties typically only become apparent after the system is integrated and in its operational environment. These properties can be split into functional and non- functional emergent properties. Functional emergent properties are related to the function of the system. Sommerville uses the example of a bike that is to be used for transportation but this property does not exist until the bike is assembled. In a complex system, where many subsystems are integrated and people are thrown into the mix, some unforeseen functional properties may arise. Predicting what these properties will be is difficult in part because users interacting with complex systems will do so in unpredictable ways. Many users will be intimately familiar with the processes the system is supporting and therefore will have ...

HW18: Chapter 18

18.4. Define an interface specification for the currency converter and check credit rating services shown in figure 18.7. Currency Converter Operation Description Lookup Display information on currency input Compare Allow user to compare multiple currency/exchange rates against one Search Allow user to search for currency based on country / location Operation Input Output Exception Lookup lookIn Currency ID Currency Name lookOut URL of page with currency information lookFault Invalid currency ID Invalid Name/None found Compare compIn PrimaryCurrencyID(1) CurrencyID (Max 10) Currency Name (Max 10) compOut URL of page with comparison search results compFault Invalid currency ID’s Invalid Name/None Search searchIn Search string searchOut URL of s...

HW17-B: Chapter 17

17.10. Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify three risks that might arise and suggest how these risks may be reduced. Three risks to consider when migrating from a desktop application to a remote service are security, decreased response time, and data management. For security, the risks of going from a desktop application to a remote service are important to handle. Interception, interruption, modification, and fabrication are methods that attacks may use to disrupt a remote system. Depending on the architecture chosen these attacks on parts of the service may disrupt the entire service. Ensuring a standard security policy is used across the system is a way to help combat this risk but there may be issues getting different system managers to adhere to the same policies. If the architecture chosen is multi-tier client-server then there may be more control over the system and therefore the secur...

HW17-A: Chapter 16

Image
16.9: Design the interfaces of components that might be used in a system for an emergency control room. You should design interfaces for a call-logging component that records calls made, and a vehicle discovery component that, given a zip code and an incident type, finds the nearest suitable vehicle to be dispatched to the incident.

HW16: Chapter 9

Software Maintenance and Lasting Professionals Three different types of software maintenance. Fault repairs to fix bugs and vulnerabilities involves fixing existing problems with the code itself, the design of the system, or requirements issues. Coding errors are the simplest to fix and the financial and time costs go up when fixing design and requirements problems. A design error may require the developer to re-write many components and requirements errors may require a system overhaul to bring it within acceptable operating levels. Environmental adaptation to adapt the software to new platforms and environments. I tend to think of this as updates to the 'things' the software runs on such as hardware or other software such as the operating system or some other piece of software that the system interfaces with. These changes may require changes to the system to allow continued operation. Functionality addition to add new features and to support new requirements. These ...