Software Design Patterns, Domain Entity Implementation, And Role Of Design Processes Within The SDLC

For the use case analysed in Question 2 of Assignment 2 identify and explain the pattern/s used and justify the decision to use that/those pattern or patterns. 

Implement the controller and domain entity classes necessary to support at least the normal flow for the use case described in Question 2 Assignment according to your design (or the design provided). Implement a test harness for the controller class which simulates and displays input from boundary classes and then receives and displays the system responses. 

Describe and discuss the role and timing of design processes within the SDLC with specific reference to:

1. Software Architecture
2. Database Design
3. User Interface Design
4. Use Case Realization
5. Detailed Design

This assessment task will assess the following learning outcome/s:

• be able to analyse and verify system requirements.
• be able to produce and verify analysis and design models for a system.
• be able to evaluate a problem and determine the appropriate architectural style for the solution.
• be able to evaluate and choose appropriate software design patterns to compose the design of a software system.

Reflection on Patterns

The glucose level application has been designed using the object oriented design pattern. This pattern models the system based on classes or objects and the relationships between them. Objects usually consist of data and operations and dynamically create instances as the system is being executed.

This particular approach has been chosen for the design of the application since it involves distinct entities with specific relations between them. These entities include the patient, the doctor and the application. Accoring to Simon & Rosch (2015), this is the context of the system in question.

Pressman (2012) argues that the major advantage of the object oriented design is that they are flexible and are easier to change than systems which have used the functional approach to be designed. Objects also reflect real world entities and models their actual behavior in the real world making it easier to understand the system and develop the design with utmost clarity.

Another major reason for choosing the object oriented design pattern is that this particular application has to be customized for the client to use. It is unique to their requirements and has to be developed from scratch. Generic or off the shelf software is not quite the option (Tsui,  Karam & Bernal, 2016).

The model-view-controller pattern separates the system into three main components (Freeman, 2015; Badenhorst,2017):-

• The model- This captures and stores the data of the system and is also known as domain of the system. It also, importantly stores business logic (Sharan, 2015).
• View- This component enables data to be retrieved from the from the model and viewed by the user
• Controller- This enables the user to manipulate both the model and the view

Software design patterns are methods that describe good software design, best principles and practices, and the way to capture experience which makes it possible for others to reuse the method (Dennis, Wixom, & Roth, 2012). The term pattern is interchangeable with word process and essentially mean the same thing.

The most popular design patterns that are currently in use include the object oriented and the model-view-controller pattern which have been discussed in the previous section. Other design patterns include:-

• Organization design pattern- describes the overall system at a higher, organizational level
• Usability design pattern- focuses on the usability of the system and is user based
• Interaction design pattern- based on how components of the system interact within the system and externally
• Configuration management design pattern- based on software version control and the establishment of baselines to track and control changes in the software.

The software development life cycle consists of a set of processes which work together to lead to a complete and functional system. According to Dennis, Wixom and Roth (2012), these processes can be broken into four broad categories, which they themselves consist of sub processes with end products. These are:-

1. System requirements specification- The functional and user requirements of the system are thoroughly established and on which design and implementation is based.
2. System design and implementation- The system is designed based on a particular pattern and architecture and actualized by coding.
3. System validation- The system is thoroughly tested for correctness in functionality and in meeting requirements
4. System evolution- The system is changed when necessary to meet customer’s needs.

Of particular interest in our case is the system design process, which can be subdivided into five aspects, which are:-

Software Architecture

Database Design

User Interface Design

Use Case Realization

Detailed Design

This is the overall structure of the proposed system and shows how it should be organized (Valacich, George & Hoffer, 2014). It depicts the main components of the system and how they relate to one another. It is the link between requirements specification and design and is vital, because it affects performance and maintainability of the system (Tsui,  Karam & Bernal, 2016).

Pattern Implementation

System architecture associates groups of system functions or features with large-scale components or sub-systems. This decomposition is then used to engineer requirements and and features of the proposed system.

The main advantages of designing and documenting system architecture is that:-

• It helps in discussion with involved stakeholders since it represents the whole system from a high-level point of view
• It assists in analysis and engineering of critical system requirements such as reliability, performance, and maintainability
• It supports the large scale reuse of software since it is a compact and manageable description of the system in its entirety.

Dennis et al. (2012) discuss that during system design and development, system analysts need to understand the information that is used and created by the system. Database design involves creating a data model, which is the formal representation of the information that is used and created by the system.

The first phase of developing a database design is developing a logical data model. This models shows the logical organization of data without showing how it will be created, stored or manipulated. The physical data model design then follows and depicts how the data will be physically stored in the database(s) and file(s).

The Entity Relationship Diagram is used to develop the logical data model and shows the relationships between various objects. Relationships include one-to-one, one-to-many, and many-to-many. This is referred to as cardinality. The logical data model is further improved through the process of normalization, which reduces redundancy and makes the model concise, flexible and complete. Typically, normalization consists of three phases:-

• First normal form- Model does not contain attributes that have repeating values for an instance
• Second normal form-Model is in 1NF and entities’ attributes are dependent on the whole identifier
• Third normal form-Model is in both 1NF and 2NF and no attributes are dependent on a non-identifier attribute.

User interface design is an important factor in systems development as it helps the user to interact with a system relative ease in terms of navigation and function execution. This is what is termed as usability in software engineering (Pressman, 2012) and brings about effective communication between the user and the application/computer.

According to Schramm, Gutwin & Cockburn (2016) the golden rules of user interface design include:-

1. Ensuring the interface is consistent
2. Giving the user control
3. Reducing the user’s memory load

All visual displays should be consistent throughout the application by sticking to a set of design principles. This means that a standard set of input mechanisms are utilized throughout the application. A good example is the windows standard menu bar. This also means that navigation mechanisms are consistently defined throughout the application.

Some of the principles of giving the user control include the following:-

• The interface should not force the user to execute undesired tasks during interaction
• Users should be able to interrupt or undo the tasks they are currently undertaking
• Interaction preferences should be robust by allowing the user to use any variety or all of the input mechanisms such as keyboard, mouse, touch screen etc.
• The interface should provide a simple, abstract view of the system and thus hiding the technical details underneath it.
• If possible, the user interface design should contain objects that can be manipulated like real world objects and provide direct interaction

A well designed user interface should make it easy for users to easily remember their way around navigation and task execution. The more difficult it is for users to remember the more mistakes they are likely to make while using the system. It also makes their learning curve  quite steep.

Use cases are all the possible ways in which actors interact with the system. They provide a high level view of the overall system requirements. Actors may be the users themselves or they may be other external systems interacting with the target system.  A typical use case is represented using ellipses and stick figures as the diagram below illustrates.

                                            Figure 1: Use case examples for a patient in the proposed system

Schramm et al. (2016) suggest that every use case can be summarized as having the following components:-

• Primary actor-This is the person/system who interacts with the target system and carries out one or more tasks.
• Goal- This is what is intended to be achieved by the task
• Preconditions- These are conditions which must be met before the use case takes place
• Triggers- These are what bring about the use case

The detailed design of the system should include the architectural design, which should have covered operational, performance, security, and cultural and political requirements. The design should further include use case analysis which covers functional requirements and process models which depict how data will be flowing through the organization. The data model depicts the data that will be handled by the system and organization and, finally the user interface design (Dennis et al., 2015).

References

Badenhorst, W. (2017). Model-View-Controller Pattern. In Practical Python Design Patterns (pp. 299-314). Apress, Berkeley, CA.

Dennis, A.,Wixom, B.H, Roth, R.M  (2012). System Analysis and Design, 5^th Ed., John Wiley & Sons, Inc.

Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object- oriented approach with UML. John wiley & sons.

Freeman, A. (2015). The Model/View/Controller Pattern. In Pro Design Patterns in Swift (pp. 527-552). Apress, Berkeley, CA.

Pressman, R. (2012). Software Engineering: A practitioner’s approach. McGraw Hill

Schramm, K., Gutwin, C., & Cockburn, A. (2016, May). Supporting transitions to expertise in hidden toolbars. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems (pp. 4687-4698). ACM.

Sharan, K. (2015). Model-view-controller pattern. In Learn JavaFX 8 (pp. 419-434). Apress, Berkeley, CA.

Simon, T., & Rösch, S. (2015, September). Comparing the object-oriented extension with the classical IEC 61131-3 regarding reusability and understandability-a case study. In Emerging Technologies & Factory Automation (ETFA), 2015 IEEE 20th Conference on (pp. 1-8). IEEE.

Tsui, F., Karam, O., & Bernal, B. (2016). Essentials of software engineering. Jones & Bartlett Learning.

Valacich, J., George, J., & Hoffer, J. (2014). Essentials of systems analysis and design. Prentice Hall Press.