TOPCIT Software | 06. Software Architecture

Summary

This script delves into the core components of software architecture, including meta-architecture, guidelines, and policies. It explains the significance of defining views, the role of software architecture in development, and the impact on project organization and system quality. The video also explores various architectural styles, such as dataflow, call-return, data-centered, and event system groups, emphasizing the importance of high-level design for creating modular, scalable, and maintainable software systems.

Takeaways

• 📚 The script discusses the components of software architecture, focusing on meta architecture, software architecture, and guidelines and policies.
• 🔍 Meta architecture provides general guidelines and design patterns for software architecture, including templates for architectural documents.
• 🌐 Software architecture is described through four views: module, component and connector, allocation, and code view, which aid in deriving context diagrams and specifications.
• 👥 Defining views should consider selection criteria and notes, as different people may have varying methods for description, such as diagrams, shapes, boxes, and lines.
• 🛠 The number of views chosen depends on factors like developer competence, domain understanding, previous project experience, and major issues to be addressed.
• 🔑 Architectural design impacts the overall system structure, project organization, and quality attributes such as functionality, availability, changeability, security, and performance.
• 📈 UML 2.0 has adopted architecture definitions from Carnegie Mellon University to simplify the representation of architectural views.
• 🛑 Guidelines and policies are crucial for determining software architecture and conducting projects based on the defined architecture, covering aspects from design to system operation.
• 🔄 The role of software architecture in development includes communication between stakeholders, early decision-making, overall system structure determination, and development project organization.
• 🔍 Types of software architecture are categorized into dataflow, call return, data centered, and event system groups, each with its own advantages and disadvantages.
• 🏗️ High-level design aims to develop a modular software architecture, involving decomposing the system into clear modules and describing their integration and interaction.
• 🔧 Object-oriented methodology involves refining object and behavior analysis models into a design model, considering logical software architecture and client-server architecture.

Q & A

What are the three main components of a software architecture in high-level design?

The three main components are meta architecture, software architecture, and guidelines and policies.

What is the role of meta architecture in software design?

Meta architecture serves as a general guideline for designing and architecture, providing a set of general decision trees and design patterns for defining the architecture of the software.

What are the four views that constitute the software architecture?

The four views are the module view, component and connector view, allocation view, and code view.

Why is it important to derive context diagrams, components specification, and interface specification from architectural design?

These derivations are important as they provide a clear understanding of the system's structure and behavior, which is essential for effective communication and further development.

How many views are typically defined in a software architecture, and what factors determine the appropriate number?

Typically, three views are defined: module view, component and connector view, and allocation view, with the code view sometimes added. The appropriate number of views depends on factors such as the competence of developers, understanding of the domain, experience from previous projects, and the major issues to be addressed.

What are the roles of software architecture in system development?

The roles include facilitating communication between stakeholders, aiding in early decision-making, determining the overall system structure, influencing the organization of the development project, and predicting the system's quality attributes.

How does the software architecture impact the development process?

The software architecture impacts the development process by guiding the design using patterns and guidelines, providing coding standards, and offering deployment guidelines, which contribute to building a structured and stable software architecture.

What are the types of software architecture grouped into, and what are some examples of each?

The types are grouped into dataflow, call return, data centered, and event system groups. Examples include batch sequential processing and filter types for dataflow, layers, main programs and subroutines, and object-oriented types for call return, centralized data repository and data-consuming client for data centered, and implicit call and explicit call types for event systems.

What is the purpose of structured high-level design in software development?

The purpose of structured high-level design is to develop a modular software architecture based on specifications, which involves decomposing the system into clear modules and describing how these modules integrate and interact.

How does the task structure design phase contribute to the development of a software system?

The task structure design phase contributes by identifying tasks that can be performed simultaneously, describing the dynamic aspects of the system, and integrating tasks within time constraints, which helps in organizing the system's processes effectively.

What are the key activities involved in determining the logical software architecture?

Key activities include vertical layering, horizontal decomposition, subsystem decomposition, technology environment definition, and subsystem interface design.

Outlines

00:00

🛠️ Software Architecture Components

This paragraph introduces the core components of software architecture, emphasizing the importance of meta-architecture, which provides general guidelines and patterns for designing software. It discusses the role of the architect and the necessity of templates for architectural documentation. The paragraph also delves into the four views of software architecture: module view, component and connector view, allocation view, and code view. It highlights the need for deriving context diagrams, component specifications, and interface specifications from architectural design. The discussion points out the variability in defining views and the importance of considering factors such as developer competence, domain understanding, and project experience when determining the number of views. The paragraph concludes by discussing the significance of quality attributes like system functionality, availability, changeability, security, and performance in the architectural design process.

05:03

🔄 Evolution of UML and Software Architecture Guidelines

The second paragraph addresses the evolution of UML from version 1.x to 2.0, noting the shift towards a less technology-dependent design, influenced by Carnegie Mellon University's SEI. It discusses how guidelines and policies are crucial for defining software architecture and conducting projects based on that architecture. The paragraph outlines the architect's role in describing development policies, including design, coding, deployment, integration, testing, maintenance, and system operation. It also explains the impact of software architecture on project organization, schedules, and configuration management. The utility programs, prototypes, and frameworks that influence software architecture design are also mentioned. The paragraph concludes by detailing the various roles of software architecture in system development, including communication, decision-making, overall structure determination, development project organization, and quality factor prediction.

10:05

🌐 Types of Software Architecture

This paragraph categorizes software architecture into four groups: dataflow, call return, data centered, and event system. It describes the characteristics and examples of each group, such as batch sequential processing and filter types for dataflow, and layers, main programs, and object-oriented types for call return. The paragraph discusses the pros and cons of pipe and filter types, layer types, main program and subroutine, and object-oriented types. It also touches on data centered groups, which handle centralized data repositories and data-consuming clients, and event system groups, which focus on changeability by reducing process dependencies. The paragraph provides a comprehensive overview of the different types of software architecture and their applications in achieving reuse, changeability, scalability, and concurrency.

15:07

🔩 Task Structure Design in Software Architecture

The fourth paragraph focuses on the task structure design within the software architecture, particularly in the context of an automobile cruise control system. It outlines the process of task identification, which includes identifying task candidates, allocating remaining processes, and integrating tasks. The paragraph explains the steps involved in each of these procedures, such as identifying asynchronous, periodic, and control patterns as task candidates. It also discusses the allocation of processes to task candidates based on criteria like sequential and control cohesion. The integration of tasks is also covered, with examples of how tasks are selected for integration based on functional cohesion. The paragraph concludes with a description of how the completed task structure is represented, including the flow of information between tasks and the composition of processes within each task.

20:09

🏗️ Logical Software Architecture and Client-Server Design

This paragraph delves into the logical software architecture determination activities, emphasizing the importance of minimizing change scope at the logical architecture level for better scalability and maintenance. It discusses vertical layering and horizontal decomposition as methods to reduce inter-layer coupling and increase functional cohesion. The paragraph also covers subsystem decomposition, explaining how client and server architectures can be realized on the same or different hardware platforms. It touches on technology environment definition, highlighting the need for developers to choose the most appropriate implementation technologies. The discussion includes the design of subsystem interfaces, especially in the context of a client-server architecture, and the importance of user interface design in system development. The paragraph concludes with a summary of eight ways to design a great user interface, emphasizing the need for a user-centric design perspective.

25:22

🎨 User Interface Design Principles

The final paragraph emphasizes the critical role of user interface (UI) design in system development. It points out that a significant portion of maintenance costs is related to the UI and highlights the potential losses due to poor usability, as estimated by various research studies. The paragraph outlines eight strategies for designing an effective user interface, advocating for a user-centric approach from the outset of system development. It underscores the importance of usability in generating business profits and improving user satisfaction, suggesting that a well-designed UI can significantly impact the success of a system.

Keywords

💡Software Architecture

Software Architecture refers to the high-level design of a software system, outlining the structural elements, their relationships, constraints, and interactions with a surrounding environment. It is a set of general guidelines and patterns that define how a software system is structured and behaves. In the video, it is central to the discussion, with various components and views being explored to understand the overall design and organization of software systems.

💡Meta Architecture

Meta Architecture is a set of general decision trees and design patterns that provide a framework for designing and creating the architecture of a software system. It includes templates for architecture documents and defines the role of the architect. The script mentions Meta Architecture as a foundational guideline that helps in setting the style and approach to software architecture design.

💡Views

In the context of software architecture, 'views' represent different perspectives or aspects of the system design. The script discusses four main views: module view, component and connector view, allocation view, and code view. These views are essential for understanding and communicating the different facets of the software's design and functionality.

💡Component

A 'component' in software architecture is a modular part of the system that encapsulates specific functionality and can be independently developed, tested, and maintained. The script refers to components in the context of the component and connector view, where they are connected by various means to form a cohesive system.

💡Connector

A 'connector' in software architecture is a mechanism that allows components to interact with each other. It defines the communication pathways and data exchange methods between components. The script mentions connectors in the context of the component and connector view, emphasizing their role in the system's architecture.

💡Guidelines and Policies

Guidelines and policies in software architecture are a set of rules and standards that guide the development process. They determine the architecture and influence project execution, including design, coding, testing, and maintenance. The script discusses the importance of guidelines and policies in shaping the development process and ensuring consistency and quality in software systems.

💡Development Process

The 'development process' encompasses the series of stages and activities involved in creating a software product, from initial design to final deployment. The script explains how software architecture plays a role in this process, influencing communication between stakeholders, decision-making, and the overall structure and organization of the project.

💡Dataflow

Dataflow architecture is a type of software architecture where the flow of data determines the process flow within the system. The script discusses dataflow as part of the types of software architecture, highlighting its ability to achieve reuse and changeability, particularly in batch sequential processing and filter types.

💡Call Return

Call return architecture is another type of software architecture that involves components calling and returning from functions or procedures. The script mentions this type as capable of achieving changeability and scalability, with examples including layered architectures, main programs and subroutines, and object-oriented types.

💡Event System

An 'event system' architecture is designed to handle events, where components or processes react to changes or signals within the system. The script describes this group as aiming to achieve changeability by eliminating dependencies between system parts, including implicit call and explicit call types.

💡High-Level Design

High-Level Design is the phase in software development where the overall structure and design of the system are determined at a high abstraction level before moving into detailed design and implementation. The script discusses the purpose and actions involved in high-level design, such as decomposing the system into modules and describing their integration and interaction.

Highlights

The importance of meta architecture in providing general guidelines and decision trees for software design.

The role of the architect in utilizing templates for architectural documents within meta architecture.

Four key views in software architecture: module view, component and connector view, allocation view, and code view.

The necessity to derive context diagrams, component specifications, and interface specifications from architectural design.

Guidelines for selecting and defining views in software architecture based on various criteria and notes.

The impact of developers' competence, domain understanding, and previous project experience on the selection of architectural views.

The significance of quality attributes such as system functionality, availability, changeability, security, and performance in architecture design.

The challenges of representing views in UML 1.x due to technology-dependent design patterns.

UML 2.0's adoption of architecture definitions from Carnegie Mellon University to ease the description of software architecture.

The role of guidelines and policies in determining software architecture and conducting projects.

The multifaceted roles of software architecture in system development, including communication, decision-making, and system structure determination.

The influence of software architecture on the organization of development projects and quality factor determination.

How software architecture informs the curriculum and training content for system developers.

The process of managing changes to software through architectural descriptions and workflows.

Classification of software architecture types into dataflow, call return, data centered, and event system groups.

Advantages and disadvantages of pipe and filter types in dataflow architecture for system design.

Characteristics and benefits of layer types, main program and subroutine, and object-oriented types in call return group architectures.

The functionality of data centered group types like repository and blackboard in managing centralized data interactions.

The purpose of event system group types in achieving changeability by decoupling process dependencies.

The structured approach to high-level design involving modular software architecture development based on structural analysis and software architecture.

The two main actions in high-level design: decomposing the system into clear functionality modules and describing their integration and interaction.

The development of module interfaces in high-level design to define externally usable components for embedded systems.

The methodology of task structure design, including task identification, remaining process allocation, and task integration.

The importance of subsystem interface design in client-server architectures for effective communication between subsystems.

The significance of user interface design in system development, emphasizing the need for usability and user-centered design.

Eight ways to design a great user interface, highlighting the importance of a user perspective in interface design.

Transcripts

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

[Music]

the components of a software

architecture that is at the heart of the

software high-level design are meta

architecture software architecture

guidelines and policies let's take a

closer look at these three components

first meta architecture is a general

guideline for designing and architecture

it is a set of general decision trees

and design patterns for defining the

architecture of the software the style

the role of the architect and consisting

of templates for the architecture

documents next the software architecture

consists of four views module view

component and connector view allocation

view and code view also as a result of

the architectural design the context

diagram components specification and

interface specification must be derived

let's take a look at what you should

know when defining views there are many

different ways to define views for each

person description method diagram shape

box line etc are all different therefore

we only need to consider the selection

criteria and notes when describing the

view also there are usually three views

such as module view component and

connect review or allocation view

in addition code view can also be added

here when you define each of you you

must describe at least of you and how

many views are appropriate depends on

factors such as the competence of the

developers the understanding of the

domain the experience of the previous

project and the major issues it should

be the basis for judging quality

attributes such as systems big function

availability change ability security and

performance and the functionality of the

key module should be described how they

are related to the inside-outside also

you need to be able to figure out the

size and scope of your system finally

you should be able to describe the

rationale for building the architecture

description in previous versions of UML

1 dot X these views were difficult to

represent this is due to the design of

excessively technology dependent

patterns or components mainly created at

the deployment level when building UML

2.0 oMG has much adopted the

architecture definition from the

Carnegie Mellon University sei so as to

make it easier to describe these areas

next guidelines and policies are that

they are for determining the software

architecture and then conduct the

project based on the defined

architecture architect should describe

and make a decision on a comprehensive

set of development policies with

guidelines and policies for design

coding deployment integration testing

tools maintenance system expansion and

system operation these software

architectures relate to the various

components of system development project

organization project schedules and

configuration management plans are based

on software architecture the utility

programs prototypes and frameworks

affect software architecture design now

I will explain the role the software

architecture and its relationship to the

development process the software

architecture has the following roles and

system development first it becomes a

means of communication between relevant

stakeholders second it is a tool to make

decisions early in the development

project in particular as it determines

the quality factor it has an overall

impact on the project organization third

it determines the overall structure of

the system fourth it affects to

determine the organization of the

development project fifth it determines

the quality factor that the system

should have this allows the architecture

to predict what quality the system will

need and what quality will have through

the architecture sixth you can decide

what curriculum and training content

delivered to system developers through

the architecture finally it informs the

process or workflow how to manage

changes to the software let me explain

how software a architect plays a role in

the overall development process

functional and non-functional

requirements act as inputs to design the

software architecture once the software

architecture is determined you can

design your software using design

patterns and design guidelines once the

software architecture is determined

coding standards and guidelines can be

provided when writing

and the software architecture provides

guidelines for deploying software on the

system with such repetition this allows

you to build a structured stable

software architecture now let's look at

the types of software architecture we

will group each type into dataflow group

call return group data centered group an

event system group first is the data

flow group types included in this group

are types that can achieve reuse and

change ability this includes the batch

sequential processing type and filter

types for the batch sequential

processing types the components are

independent programs each step must end

before starting the next step and data

in each batch step has the entirely

moving characteristic between steps

let's look at the pros and cons of pipe

and filter types first the pros are easy

to understand the data flow control

process having specialized analysis

functions enable filter reuse achieve

concurrency and easy to maintain and

expand in contrast there are cons and

that it is not suitable for highly

interactive systems difficult to

maintain consistency between many

relevant data increases complexity and

can cause the performance issues next is

the call return group types included in

this group can achieve change ability

and scalability this includes layers

main programs and subroutines and

object-oriented types first the pros and

cons of layer types pros include

providing a design based on abstraction

levels improving scalability providing

high reusability and portability the

cons are that it is difficult to apply

to all systems and in some cases it can

be very difficult to find the right

level of abstraction

the following are the main program and

subroutine it has excellent reusability

and ease of system evolution however

components have the cons that they have

to give up control over the calculations

that the system processes and require

careful handling of the data

next is the pros and cons of

object-oriented types implementation is

easy to change and there is an pros that

design of problem area analysis is

intuitive but you have to know the

identifier zuv other objects and you

have to modify other objects when you

change the object identifier next is

data centered group the types contained

in this group are used when data is

concentrated in the system and multiple

clients interact with the system to

obtain the data the components are

centralized data repository and data

consuming client here are the storage

types and blackboard types the

repository is a passive data center a

type that check to see if a client needs

to fetch data a blackboard is an active

data center a type that notified changes

to relevant clients when data changes

next is the event system group the types

contained in this group are aimed at

achieving change ability by eliminating

the dependencies of various parts of the

process through independent processes or

objects this includes implicit call

types and explicit call types for the

implicit call type a component is a

module with an interface that provides a

collection of procedures and a set of

events also it connects to event

registration and procedure call as a

constraint the event provider does not

know which components are affected by

the event in case of the explicit call

type every time a system function is

changed the other module that imports

the module must also be changed in

addition reflection provides a mechanism

to change the system configuration or

behavior at any time of execution MVC

and PA see which allows the system to

respond flexibly to changes by sharing

responsibilities brokers provides

distributed transparency in a

distributed environment microkernel

types

divide the system into core parts and

change parts to accommodate frequently

changing requirements the purpose of

structured high-level design is to

develop a modular software architecture

based on specifications developed

through structural analysis and software

architecture two big actions must be

described first decompose the system

into modules that provide clear

functionality second describe how the

decomposed modules integrate and inter

work together in particular various

items must be organized to describe how

to integrate and inter work first it

develops a module interface that defines

the modules components that can be used

externally for a typical embedded system

using the C language functions that can

be called from other modules global

variables that can be assessed data

structures and macros make up the

modules interface it also determines the

usage criteria for various resources

such as error handling criteria threads

timers interrupts and alarms shared

within the overall modular structure and

technology standards such as the data

types that are shared on the development

platform are determined although various

techniques can be used to describe such

a module structure the structural

high-level design methodology is divided

into a task structure design which shows

dynamic aspects and a module structure

design which describes static aspects

task structure design step identify the

tasks that can be performed

simultaneously on the system based on

the output of analysis and describe the

dynamic aspects of the system module

structure design phase identifies

modules that are development units based

on output of analysis and task structure

and specify technical standards and

module interfaces

we will continue to explain the process

of high-level design based on the

structural analysis results of the

automobile cruise control system

presented on the screen

the task structure design shows all the

processes identified in automobile

cruise control as you can see in the

figure the figure is an example for

describing the task identification

process not the regular output created

in the development methodology process

this figure shows all the processes

identified so far showing that the

patterns are asynchronous periodic and

control let's look at the procedures for

a task structure design in a structural

design methodology the task structure is

designed according to the three steps

task identification procedure proposed

by Hassan Gama the task identification

procedure consists of three steps task

candidate identification is the

identification of processes that require

their own execution remaining process

allocation refers to allocating

processes that have not been assigned

their own tasks to task candidates and

tasks integration means integrating

tasks candidates within a time

constraint let's take a closer look at

each of these three steps of task

identification procedures first let's

look at identifying candidate tasks

according to the technique described

processes according to the asynchronous

periodic and control patterns become

task candidates the table lists the

identified task candidates on the left

are tasks candidates processes in the

middle and criteria for selecting them

on the right next is the allocation of

the remaining process the figure shows

that the process identified as remaining

processes in the automobile cruise

control example are distributed the

figure shows have the four tasks that

were not identified in the previous step

are assigned to some task candidates the

table lists the processes that have been

allocated and their criteria

tasks candidates include task 3 and task

4 and the processes allocated to them

have processes determine the speed and

there are processes related to the

preemption of the expected speed in

addition each process is mapped to task

candidate according to the degree of

sequential cohesion and control cohesion

next is the merging tasks automobile

cruise control example shows the cases

where task integration is possible as

per the table the table shows which

tasks have been integrated how they were

selected and the criteria definition for

example you can see that task 1 and task

to integrate due to functional cohesion

that is mutually exclusive execution

characteristics we will complete the

task structure of the automobile cruise

control system through task candidate

identification remaining process

allocation and task integration the

completed task structure is the same as

the screen in figure the diamond

indicates the identified task and the

line between the tasks indicates the

flow of information required between the

tasks each of these tasks consists of

processes presented in the screen in the

table you can see how each task is

mapped to each process and how they are

composed or connected each other now

let's look at high-level design method

by object oriented methodology in

general the object oriented development

methodology does not have a clear

boundary between object and behavior

analysis an object and behavior design

therefore the object and behavior

analysis models are refined to a more

sophisticated design model that matched

to the selected software description and

detailed implementation description is

established in this case the object and

behavior analysis model evolves into a

design model during the high-level

design phase developers perform

activities to describe the system in

terms of logical software architecture

and

the implementation strategies to

implement the system in terms of

client-server architecture first let's

look at logical software architecture

determination activities this activity

refers to the activities of layering and

decomposing the system to have a low

degree of coupling the main goal of this

software architecture determination is

to minimize the scope of change at the

logical architecture level not at the

unit class level as minimizing the scope

of change is closely related to software

scalability and maintenance the coupling

issue must be solved well in terms of

logical architecture in principle the

lower the degree of coupling the easier

the software is to expand and maintain

and in a software architecture with a

high degree of coupling a change in a

particular part will impact changes in

other parts that depend on it

determining the logical software

architecture to decompose these systems

is executed regardless of the

implementation strategy the following

table summarizes the activities briefly

for determining logical software

architecture I will continue to explain

vertical layering and horizontal

decomposition vertical layering is the

packaging of boundary classes control

classes and object classes shown in

class diagrams and placing them in a

vertical hierarchy I will explain them

through the picture the picture shows a

layered architecture that is packaged

vertically into three groups for the

depositor service system boundary

classes are packaged as GUI groups from

class diagrams created in behavior and

analysis activities control classes are

also packaged into workflow groups you

can see object classes are packaged as

domain groups in this example the

dependency represented by the dotted

arrow indicates that the higher layer

uses the lower layer service next

horizontal decomposition can be

performed to reduce inter layer coupling

when certain layers are complex in

addition the classes in the same layer

can be performed by the developers into

with criteria or a systematic analysis

method

let me explain with the example the

figure is a architecture in which the

domain group hierarchy previously

discussed is decomposed horizontally

again classes with similar

functionalities are grouped together in

other words horizontal decomposition was

performed to increase the functional

cohesion and have the grounds that

customer management and account

management aspects can be functionally

separated this time I will explain

subsystem decomposition like layering

and decomposition client and server

architectures are also logical concepts

in other words from a software

development perspective a client-server

architecture can be realized on the same

hardware platform or on different

hardware platforms the example on the

screen shows the software development

architecture for fat clients and thin

clients assuming the package of vertical

layering architecture as discussed above

are deployed on different hardware

platforms looking at the first fat

client each client consists of GUI group

workflow group and domain group while

thin clients consists of server workflow

group domain group client and GUI group

the figure on the screen is a subsystem

architecture diagram decomposed into

subsystems according to the previous

activities the left side is the

subsystem architecture of fat client and

the right side is the subsystem

architecture of thin client next the

technology environment definition will

determine the technology environments

for the client and server subsystems and

may include technology selection for any

middleware that connects the client and

server

in other words when decomposing a

subsystem into a client-server

architecture developers must choose the

most appropriate implementation

technologies to do this they will

determine the technologies for object

oriented programming language operating

system middleware user interface

development tools and database

management system currently technology

environments that support an

object-oriented paradigm are very broad

and constantly evolving into or friends

of rising new technologies as

technologies to implement

object-oriented methodologies are too

broad the high-level design a specific

development language specific middleware

specific user interface implementation

techniques or a specific database

management system is not willing to be

confined with specific one just like all

object-oriented methodologies therefore

after selecting the technology

environment the design phase should be

dependent on the developers expert

knowledge and specific technologies the

figure on the screen is a client-server

architecture from a software deployment

perspective a client or server has a

separate hardware platform and chose

typical technologies required to

implement software with a client-server

architecture this picture shows a

web-based software architecture deployed

on three-tier hardware platforms it

demonstrate the core skills required to

build a web-based system a web based

system is an extension of a

client-server architecture with a

website where the business logic can

place on the server side or client side

next let's look at subsystem interface

design once the subsystem decomposition

and the technical environment are

established the interface to the derived

subsystems starts to be design first

this example assumes the following

scenarios assume that you have assigned

the workflow group package and the

domain group package to the application

server as shown in the thin client

architecture and the diagram of first

technology environment it is also

assumed that the interface technology

between thin client and application

server

is remote method invocation RMI provided

by java then this will require a

subsystem interface design to use remote

method calls between classes belonging

to GUI group and classes belonging to

workflow group the figure on the screen

defines the interfaces that classes

belonging to workflow group provide to

the classes belonging to the client

subsystem the user interface is defined

as the interface between the person and

the system or the information channel

between the user and each system

therefore to make the system more easier

to use user interface design means to

identify the problem of information

exchange between user and system then

systematically designed to resolve

implement and test them especially in

modern times in an environment in which

a computer directly or indirectly

occupies a large part of our lives the

interface between the computer and human

being is becoming an important issue

than anything else during development of

the system there is a statistics that

80% of the overall maintenance costs are

related to the UI in addition jakob

nielsen author of usability engineering

predicts that if a better navigation

system is not built and a rigid internal

design standard is not enforced the cost

of bad usability of internet usage will

be exponentially increased in worldwide

zona research estimates that ecommerce

companies are losing more than 58

million dollars a month from frustrated

customers due to web pages

therefore the UI process must be applied

from the beginning of system development

and the ideas that shortening the

development cycle meeting the user

requirements increasing the usability

and helps to generate a bigger business

profits are spreading the following is a

summary of eight ways to design a great

user interface it is necessary for the

design of the user perspective so please

refer to them

[Music]

[Music]

you

[Music]