Sunday, 10 February 2019

Architectural Design and Models of Software Architecture (Group 1)


DFP5043 – Software Requirement and Design
Tutorial Lab4
Instruction:
Discuss and contribute together to answer  
the questions below and post the answer to the class's blog.
Don't forget to write your name in the blog.

Define and draw example of architectural design and models of software architecture below:
i.                    Architectural Design
ii.                  Logical View
iii.                Process View
iv.                 Development View
v.                   Physical View
vi.                 Scenario
  • Architectural Design
An architectural model is a rich and rigorous diagram, created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture.
Image result for architecture diagram in software engineering
  • Logical View
The logical view is concerned with the functionality that the system provides to end-users. UML diagrams used to represent the logical view include, class diagrams, and state diagrams or which shows the key abstractions in the system as objects or object classes.
Image result for logical view
  • Process View
The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system.
The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML diagrams to represent process view include the activity diagram.
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency.
In the Unified Modelling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores

    • Development View
    The Development Viewpoint is a considerable amount of planning and design of the development environment is often required to support the design and build of software for complex systems. It is the role of the Development view to address these aspects of the system development process.

    Definition
    Describes the architecture that supports the software development process.
    Concerns
    • module organization
    • common processing
    • standardization of design
    • standardization of testing
    • instrumentation
    • codeline organization
    Models
    • module structure models
    • common design models
    • codeline models
    Pitfalls
    • too much detail
    • overburdening the AD
    • uneven focus
    • lack of developer focus
    • lack of precision
    • problems with the specified environment
    Stakeholders
    Production engineers, software developers and testers.
    Applicability
    All systems with significant software development involved in their creation.

    Image result for development view/implementation view example
    • Physical View
    The physical view depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer as well as the physical connections between these components. This view is also known as the deployment view. UML diagrams used to represent the physical view include the deployment diagram. The following diagram is the UML deployment diagram:
    Image result for deployment diagram in architectural design

    • Scenario
    The description of an architecture is illustrated using a small set of use cases, or scenarios, which become a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view. The following diagram is the use case view.
    Image result for use case diagram


    Overall:
    Image result for what is physical view of architectural design


    GROUP 1:
    • ARIF ASNAWI BIN MOHD PAUZI (01DIS17F1047)
    • MUHAMMAD FARID BIN MOHD ARIFFIN (01DIS17F1041)
    • MUHAMMAD AKMAL BIN AHMAD FADZIL (01DIS17F1040)
    • ABDUL RAHMAN BIN MESRUN (01DIS17F1061)
    • MUHAMMAD HASNUDDIN BIN SALAHUDDIN (01DIS17F1062)
    • MUHAMMAD AMIRUDDIN BIN ABDUL KADIR (01DIS17F1034)
    • MUHAMMAD HAFIZ BIN ZUHARI (01DIS17F1037)
    • AHMAD THAQIF ILMAM BIN ABDUL AZIZ (01DIS17F1035)
    • NURUL IZZAH BINTI KAMAL FAISAL (01DIS17F1049)
    • MIMI AMIRAH BINTI CHE ABDUL (01DIS17F1045)
    • NUR AFIQAH BIN MOHAMAD RAMLEE (01DIS171057)
    • KU NURAL' IZZATI BINTI KU KAMARUDZAMAN (01DIS17F1064)
    • NURUL ELISYAH BINTI MUHAMMAD ARSHAD (01DIS17F1033)
    • YASHELA A/P CHANDRANSANGRAN (01DIS17F1101)

    Architectural Design and Models of Software Architecture (Group 3)

    DFP5043 – Software Requirement and Design

    Group 3 – MOHAMMAD HUZAIFAH BIN MOHAMED YUSOFF (01DDT17F1007)
    LUKMAN HAKIM BIN MAMAT (01DDT17F1001)
    MOHAMMAD AMIRUL SHAH BIN MOHAMAD NASIR (01DDT17F1021)
    MUHAMMAD ALIF BIN ZAKARIA (01DDT17F1014)
    AHMAD FITRI BIN AHMAD (01DDT17F1006)
    AHMAD LUQMAN BIN ADAM (01DDT17F1009)
    MUHAMAD AFIQ FAHMI BIN JINS (01DDT17F1027)





    Architectural Design is a creative process so the process differs depending on the type of system being developed.

    The logical view is concerned with the functionality that the system provides to end-users. UML diagrams are used to represent the logical view include, class diagrams, and state diagrams or which shows the key abstractions in the system as objects or object classes.

    The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behaviour of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability. UML diagrams to represent process view include the activity diagram.

    The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram.
    The physical view depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer as well as the physical connections between these components. This view is also known as the deployment view. UML diagrams used to represent the physical view include the deployment diagram.

    The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view.

    Architectural Design and Models of Software Architecture (Group 2)

    Architectural View Model


    ARCHITECTURAL DESIGN 
    ²An early stage of the system design process.
    ²Represents the link between specification and design processes.
    ²Often carried out in parallel with some specification activities.
    ²It involves identifying major system components and their communications.

    Logical View 

    To provide a basis for understanding the structure and organization of the design of the system, an architectural view called the Logical View is used in the Analysis & Design workflow. There is only one logical view of the system, which illustrates the key use-case realizations, subsystems, packages and classes that encompass architecturally significant behavior. The logical view is refined during each iteration.


    There are four additional views, the Process View, Development View, Physical View and Scenario(also known as the Use Case View).

    Development view

    It describes the architecture that supports the software development process.

    For example :




    Physical view
    Physical view refers to the way data are physically stored and processed in a database.
    For example:

    Scenario
    The description of an architecture is illustrated using a small set of use cases, or scenarios, which become a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view.

    Post By Group 2:

    NOOR SUFIATUL ASNI (1054)
    FARAH NADIAH (1062)
    NURATUL AIN (1052)
    SITI HAJAR (1044)
    INSYIRAH (1039)
    NADIAH (1098)
    FAIZAH (1036)
    ARINAH (1059)
    FILZAH (1060)



    Sunday, 13 January 2019

    Software Requirement and Design (Group 2)


    DFP5043 – Software Requirement and Design
    Group 2
    Huzaifah, Muiz, Hakim, Amirul, Fitri, Afiq, Alif, Ahmad Luqman

    Tutorial Lab3
    Instruction:
    Discuss and contribute together to answer each of the questions below and post the answer to the class blog.

    1. Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:
    • A system to control anti-lock braking in a car
    • A virtual reality system to support software maintenance
    • A university accounting system that replaces an existing system
    • An interactive travel planning system that helps users plan journeys with the lowest environmental impact

    a)     Anti-lock braking system is the system that need a lot of testing and the flow would likely to go back and forth which make Waterfall model out of the question the only reasonable model used would be incremental development.

    b)     Virtual reality system is another system that will change based on customer feedback. Incremental development with an agile process may be used.

    c)     University accounting system is a system where it’s commonly being used in other industry and would likely already have a model that can be modified to customer needs. Therefore, a reuse-based model can easily be implemented in this system.

    d)     Interactive travel planning system is a system that changes based on user feedback and probably would have to extend their compatibility with another system in the future, there’s also a need of usability engineering which is based on user experience and the ergonomics of the design would also affect the end user efficiency, these changes need to be improved overtime so an incremental development approach is the most suitable to give out the best of the system.



    2. Consider the reuse-based process model shown in page 14 in the slide, explain why it is essential to have two separate requirements engineering activities in the process.

    In a reuse based process, you need two requirements engineering activities because it is essential to adapt the system requirements according to the capabilities of the system to be reused. These activities are:
    a)      An initial activity where you understand the function of the system and set out broad requirements for what the system should do. These should be expressed in sufficient detail that you can use them as a basis for deciding of a system that satisfies some of the requirements and so can be reused.
    b)      Once systems/components have been selected, you need a more detailed requirements engineering activity to check that the features of the reused software meet the business needs and to identify changes and additions that are required.

    3. Based on page 18 in the slide, suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements
    Engineering process.

    ·         The user requirement are intended to describe the system’s function and features from a user perspective and it is essential that user understand these requirement. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain.
    ·         The system requirement are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situation where development is outsourced and the development team need a complete specification of what should be develop. The system requirement are develop after user requirement are developed after user requirement are developed after user requirement have been established.


    Software Requirement and Design (Group 4)


    DFP5043 – Software Requirement and Design
    Tutorial Lab3
    Instruction:
    Discuss and contribute together to answer each of
    the questions below and post the answer to the class blog.

    1. Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the

    following systems:
    • A system to control anti-lock braking in a car
    • A virtual reality system to support software maintenance
    • A university accounting system that replaces an existing system
    • An interactive travel planning system that helps users plan journeys
    with the lowest environmental impact


    a) Anti-lock braking system .This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages.

    b) Virtual reality system. This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used.

    c)University accounting system .This is a system whose requirements are fairly well-known and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this.

    d) Interactive travel planning system .System with a complex user interface but which must be stable and reliable. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.




    2. Consider the reuse-based process model shown in page 14 in the slide, explain why it is essential to have two separate requirements engineering activities in the process.



    These activities are:

     Requirement specification
     An initial activity where you understand the function of the system and set out broad requirements for what the system should do. These should be expressed in sufficient detail that you can use them as a basis for deciding of a system/component satisfies some of the requirements and so can be reused.

    Requirement modification
     Once systems/components have been selected, you need a more detailed requirements engineering activity to check that the features of the reused software meet the business needs and to identify changes and additions that are required.





    3. Based on page 18 in the slide, suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.

    There is a fundamental difference between the user and the system requirements that mean they should be considered separately.

    a)     The user requirements are intended to describe the system’s functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain.




    b)     The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established.

    NAME:


    • Nazaratul Kasrina binti Kamarulzaman (01DDT17F1011)
    • Nurul Adlina Binti Muhamad Zainal (01DDT7F1019)
    • Anis Wahida Binti Razik (01DDT17F1020)
    • Siti Nur Mariah Binti Abdullah (01DDT17F1030)
    • Muhamad Aidil Irfan bin Ahmad Azali (01DDT17F1028)
    • Mohammad Aizat Nazmi bin Mohd Satar (01DDT17F1034)
    • Azrul Faiz bin Abd Aziz (01DDT17F1029)
    • Mohammad Raihan bin Mohd Johari (01DDT17F1031)

    Software Requirement and Design (Group 1)

    DFP5043 – Software Requirement and Design
    Tutorial Lab 3
    Instruction:
    Discuss and contribute together to answer each of the questions below and post the answer to the class blog.

    1. Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:
    A system to control anti-lock braking in a car
    Anti-lock braking system  This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages.

    • A virtual reality system to support software maintenance
    Virtual reality system. This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used.

    • A university accounting system that replaces an existing system
    University accounting system. This is a system whose requirements are fairly well-known and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this.

    • An interactive travel planning system that helps users plan journeys
    with the lowest environmental impact
    = Interactive travel planning system.  System with a complex user interface but which must be stable and reliable. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.


    2. Consider the reuse-based process model shown in page 14 in the slide, explain why it

    is essential to have two separate requirements engineering activities in the process.
    ·         In a reuse based process, you need two requirements engineering activities because it is essential to adapt the system requirements according to the capabilities of the system/components to be reused.
    ·         These activities are:
    a) Requirement specification: An initial activity where you understand the function of the system and set out broad requirements for what the system should do. These should be expressed in sufficient detail that you can use them as a basis for deciding of a system/component satisfies some of the requirements and so can be reused.
    b) Requirement modification: Once systems/components have been selected, you need a more detailed requirements engineering activity to check that the features of the reused software meet the business needs and to identify changes and additions that are required.

    3. Based on page 18 in the slide, suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements
    engineering process.

    a) The user requirements are intended to describe the system’s functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain.

    b) The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established.

    GROUP 1:

    • ARIF ASNAWI BIN MOHD PAUZI (01DIS17F1047)
    • MUHAMMAD FARID BIN MOHD ARIFFIN (01DIS17F1041)
    • MUHAMMAD AKMAL BIN AHMAD FADZIL (01DIS17F1040)
    • ABDUL RAHMAN BIN MESRUN (01DIS17F1061)
    • MUHAMMAD HASNUDDIN BIN SALAHUDDIN (01DIS17F1062)
    • MUHAMMAD AMIRUDDIN BIN ABDUL KADIR (01DIS17F1034)
    • MUHAMMAD HAFIZ BIN ZUHARI (01DIS17F1037)
    • AHMAD THAQIF ILMAM BIN ABDUL AZIZ (01DIS17F1035)
    • NURUL IZZAH BINTI KAMAL FAISAL (01DIS17F1049)
    • MIMI AMIRAH BINTI CHE ABDUL (01DIS17F1045)
    • NUR AFIQAH BIN MOHAMAD RAMLEE (01DIS171057)
    • KU NURAL' IZZATI BINTI KU KAMARUDZAMAN (01DIS17F1064)
    • NURUL ELISYAH BINTI MUHAMMAD ARSHAD (01DIS17F1033)
    • YASHELA A/P CHANDRANSANGRAN (01DIS17F1101)

    Software Requirement and Design by GROUP 3




    1.     Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:

    a)     Anti-lock braking system  This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages.

    b)     Virtual reality system  This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used.

    c)     University accounting system  This is a system whose requirements are fairly well-known and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this.

    d)     Interactive travel planning system  System with a complex user interface but which must be stable and reliable. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.



    2.       Explain why it is essential to have two separate requirements engineering activities in the process.



    Requirements specification
    Requirement Modification
    which is the activity of translating the information gathered during the analysis activity into a (formal or informal, depending on the underlying process used) document that defines a set of requirements
    Information about component that is selected during component analysis is used to analysis requirement specification. Requirements are modified according to available components. Requirement modification is critical then component analysis activity is reused to find relative solution.

    Two types of requirements may be included in this document:

          a.    User requirements are abstract statements of the system requirements for the customer and end-user of the system
           b.   System requirements are a more detailed description of the functionality to be provided.
    Elements: 

    All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces.




    3.       Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.


    There is a fundamental difference between the user and the system requirements that mean they
    should be considered separately.




    a)The user requirements are intended to describe the system’s functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain.

    b)The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be
    used in situations where development is outsourced and the development team need a complete
    specification of what should be developed. The system requirements are developed after user
    requirements have been established.

    BY GROUP 3

    NOOR SUFIATUL ASNI (1054)
    FARAH NADIAH (1062)
    NURRATUL AIN (1052)
    SITI HAJAR  (1044)
    INSYIRAH (1039)
    NADIAH (1098)
    FILZAH (1060)
    FAIZAH (1036)
    ARINAH (1059)


    EXAMPLES OF MOST APPROPRIATE GENERIC SOFTWARE PROCESS MODEL



    G3

    1. Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:
    • A system to control anti-lock braking in a car
    • A virtual reality system to support software maintenance
    • A university accounting system that replaces an existing system
    • An interactive travel planning system that helps users plan journeys with the lowest environmental impact

    a)     Anti-lock braking system  This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages.

    b)     Virtual reality system  This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used.

    c)     University accounting system  This is a system whose requirements are fairly well-known and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this.

    d)     Interactive travel planning system  System with a complex user interface but which must be stable and reliable. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.


    UML Group 1

    DFP5043 – Software Requirement and Design Lab 7 Instructions: Discuss with your group. Answer all questions and post the question an...