Object-oriented Information Systems

UML

Unit 3

This unit jumps into the Unified Modelling Language (UML), which represents a tool to design the software system before its implementation into code. It is distinguished into three categories, behavioural diagrams, structural diagrams and architectural models. In summary, a part of UML diagrams describe the system's behaviour, and other diagrams analyse and represent the structure of the software.
Behavioral diagrams are responsible for the interaction between software components over time, and the use case diagram and activity diagram are the most deployed behavioural diagrams.
Structural diagrams, by contrast, represent the relationship between the system components. The most deployed structural diagram is the class diagram.
Finally, Architectural Models include structural and behavioural aspects and demonstrate the framework of the software system.

Navigation

Outcomes

  • Summary of the learning outcomes

This unit aims to:

  • Recognise the syntax used to design UML models
  • Distinguish between the UML models which are applicable at various stages of the Software Development Life Cycle (SDLC)
  • Develop UML models using open source tools

  • Reflection

What exactly have I learnt and how?

This unit taught me about UML diagrams and why they help develop software. Whether layouts, mind maps or other outlines, it requires a temporary structure before starting to write an essay. The same applies to software development. Thus, due to the standardized UML diagrams, it is easier to communicate with developers and get an overview of the software system design at many stages of the software development lifecycle. However, it also has drawbacks. Diagrams with insufficient information can cause too many misunderstandings. Hence, the diagram should be not just a brief outline; it requires all the information of the software to increase the quality and efficiency of development.

  • Notes

Notes from the elaboration of the unit, various meetings, and feedback from team members and tutors

Summary post of the collaborative discussion topic: "Factors Influencing Reusability"
Regarding feedback and initial input from my peers, we all agreed that requirements analysis (RA) is a top priority before developers start coding. Knowing what is required and given from scratch is essential to utilize reusable software components effectively. Thanks to a peer, I need to weigh the reusable factor "An algorithm used in the program" (AP) higher than I expected. My first approach was that algorithms are too special to be reusable. However, many off-the-shelf algorithms are reusable and save a massive time during software development, e.g. hashing passwords.

Contact Me