Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 38 views

    Chapter Three: Design 3.1 Purpose and Goals of Design: 3.2 Component Diagram

    Uploaded by

    Tolosa Tafese
    The chapter discusses system design which transforms the analysis model into a design model that considers non-functional requirements. It focuses on using UML diagrams like component, deployment, and class diagrams to model the system. Component diagrams visualize physical components, deployment diagrams show hardware topology, and class diagrams show classes, relationships, attributes and operations. The system is decomposed into subsystems like the administrator, officer, and customer systems to reduce complexity.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Chapter Three: Design 3.1 Purpose and Goals of Design: 3.2 Component Diagram

    Uploaded by

    Tolosa Tafese
    38 views7 pages
    The chapter discusses system design which transforms the analysis model into a design model that considers non-functional requirements. It focuses on using UML diagrams like component, deployment, and class diagrams to model the system. Component diagrams visualize physical components, deployment diagrams show hardware topology, and class diagrams show classes, relationships, attributes and operations. The system is decomposed into subsystems like the administrator, officer, and customer systems to reduce complexity.

    Original Title

    System design

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The chapter discusses system design which transforms the analysis model into a design model that considers non-functional requirements. It focuses on using UML diagrams like component, deployment, and class diagrams to model the system. Component diagrams visualize physical components, deployment diagrams show hardware topology, and class diagrams show classes, relationships, attributes and operations. The system is decomposed into subsystems like the administrator, officer, and customer systems to reduce complexity.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    38 views7 pages

    Chapter Three: Design 3.1 Purpose and Goals of Design: 3.2 Component Diagram

    Uploaded by

    Tolosa Tafese
    The chapter discusses system design which transforms the analysis model into a design model that considers non-functional requirements. It focuses on using UML diagrams like component, deployment, and class diagrams to model the system. Component diagrams visualize physical components, deployment diagrams show hardware topology, and class diagrams show classes, relationships, attributes and operations. The system is decomposed into subsystems like the administrator, officer, and customer systems to reduce complexity.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    You are on page 1of 7

    CHAPTER THREE: DESIGN

    3.1 Purpose and goals of design


    System design is the transformation of the analysis model into a system design model. Up to now
    we were in the problem domain. System design is the first part to get into the solution domain in
    a software development. This chapter focuses on transforming the analysis model into the design
    model that takes into account the non-functional requirements and constraints described in the
    problem statement and requirement analysis sections discussed earlier.
    The purpose of designing is to show the direction how the system is built and to obtain clear and
    enough information needed to drive the actual implementation of the system. It is based on
    understanding of the model the software built on. The objectives of design are to model the
    system with high quality. Implementing of high quality system depend on the nature of design
    created by the designer. If one wants to change to the system after it has been put in to operation
    depends on the quality of the system design. So if the system is design effetely, it will be easy to
    make changes to it. In system design how different system can build one system and how
    different system decomposed. In system design we use different UML diagrams such as
    deployment diagram which show how the system will deployed on computers. In other words, it
    shows which component of the software will install on which machine and how they
    communicate with each other if they are on different machines, component diagram - shows how
    objects (classes) in your system will grouped together and form components, persistence
    modeling and others. During system design, we focus on the processes, data structures, and
    software and hardware components necessary to implement it.

    3.2 Component diagram

    Component diagram is a special kind of diagram in UML. The purpose is also different from all
    other diagrams discussed so far. It does not describe the functionality of the system but it
    describes the components used to make those functionalities.

    So from that point component diagrams are used to visualize the physical components in a
    system. These components are libraries, packages, files etc.

    Component diagrams can also be described as a static implementation view of a system. Static
    implementation represents the organization of the components at a particular moment.
    A single component diagram cannot represent the entire system but a collection of diagrams are
    used to represent the whole.

    So the purpose of the component diagram can be summarized as:

     Visualize the components of a system.

     Construct executables by using forward and reverse engineering.

     Describe the organization and relationships of the components.

    Manage user
    account

    Approve

    Administrator
    View comment Security

    Announce Officer
    renewal date

    Prepaire license Accountant

    Trade registration Database


    Work
    coordinator
    View report
    Customer
    Send feedback

    Register payment

    Apply

    View notification

    Send comment

    Fig.1 Component diagram

    3.3 Deployment diagram


    The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
    used for describing the hardware components where software components are deployed.
    Component diagrams and deployment diagrams are closely related.

    Component diagrams are used to describe the components and deployment diagrams shows how
    they are deployed in hardware.

    UML is mainly designed to focus on software artifacts of a system. But these two diagrams are
    special diagrams used to focus on software components and hardware components.

    So most of the UML diagrams are used to handle logical components but deployment diagrams
    are made to focus on hardware topology of a system. Deployment diagrams are used by the
    system engineers.

    The purpose of deployment diagrams can be described as:

     Visualize hardware topology of a system.

     Describe the hardware components used to deploy software components.

     Describe runtime processing nodes.


    Web server

    Manage account

    Client browser MYSQL


    Apply
    database
    server
    Addminstrator
    Send comment
    MYSQL DB Security
    connection
    View notification
    Customer
    HTTP
    Aprove
    Officer
    Anounce renewal
    date Database
    query

    Prepare license
    Accountant
    Trade registration

    View coment
    Work
    coordinator
    Registor
    payment

    Send feedback

    View report

    Fig.2 Deployment diagram

    3.4 Class diagram


    Class modeling shows the classes of the system, their interrelationships (including inheritance,
    aggregation, and association), and the operations and attributes of the classes. It shows the static
    features of the actors and do not represent any particular processing.
    Customer Employee License
    Eid: Varchar(20) Name: Varchar(20)
    Fname: Varchar(20) Fname: Varchar(20) TIN: Varchar(20)
    Lname: Varchar(20) Lname: Varchar(20) Address: Varchar(20)
    Age: Varchar(20) Role: Varchar(20) Code: Varchar(20)
    Phone number: Varchar(20) Phone number: Varchar(20) Nationality: Varchar(20)
    Address: Varchar(20) Address: Varchar(20) Serial_no: Varchar(20)
    Email address: Varchar(20) Email address: Varchar(20) Date:date
    Capital: Varchar(20)
    Trade type: Varchar(20) View feedback() License()
    Date:date View payment() Login()
    Approve() Logout()
    Send comment() Register payment()
    Send request() View report()
    Create account() View comment()
    Announce() Login()
    Notify() Logout()
    Login()
    Logout() Payment

    Fname: Varchar(20)
    Administrator Lname: Varchar(20)
    User account Pid: Varchar(20)
    Fname:Varchar(20) Payment reason: Varchar(20)
    Lname:Varchar(20) Fname: Varchar(20) Date: Date
    Address:Varchar(30) Lname: Varchar(20)
    Email address:Varchar(40) Address: Varchar(20) Payment()
    Sex:Text Username: Varchar(30) Login()
    Aassword: Varchar(30) Logout()
    Create account()
    Delete account() Signup()
    Update account()
    Login()
    Logout()

    Fig. 3 class diagram

    3.5 System Decomposition


    System decomposition refers to the process by which a complex system is broken down into
    parts that are easier to conceive, understand, program, and maintain. To reduce the complexity of
    the solution domain, we decompose our system into simpler parts, called subsystems, which are
    made of a number of solution domain classes. In the case of complex subsystems, we recursively
    apply this principle and decompose a sub- system into simpler subsystems. We decompose trade
    registration and license system in to five subsystems. These are:
     Administrator’s system
    - Manage user account
    - Create user account

     Officer’s system
    - Approve
    - View comment
    - Announce renewal date
    - Prepare license
    - Trade registration system
     Customer’s system
    - Apply
    - View notification
    - Send comment
     Accountant’s system
    -Register payment
     Work coordinator’s page
    -View report
    -Send feedback
    Online trade
    registrastion and
    license system

    Workcoordinator
    Administrator Customer Accountant subsystem
    Officer subsystem
    subsystem subsystem subsystem

    Annou View Send


    Manage nce prepar Apply notific comm Rigiter
    user Appro renew e lice ation ent payment Send
    account ve al View report
    nse feedback
    date

    Fig.4 System decomposition Diagram

    3.5 Persistence modeling for object oriented database


    Relational databases do not completely support object-oriented concepts, so the design of the
    database is different from the design of class diagram. Persistence models enable to design the
    schema of the database.

    Mapping
    In order to store information persistently we map objects into tables and the attributes into fields
    to the specific table based on the objects found on the system.

    You might also like