Visual Architecture
Requirements Definition
Version:
1.0
Date: 2010-09-30
Visual Architecture
Requirements Definition
Version 1.0
Page 1
Doc. No.:
Visual Architecture
Requirements Definition
Version:
1.0
Date: 2010-09-30
Revision History
Date
Version
Description
Author
2010-09-30
0.01
Initial Draft
Sarah Kuria
01.10.10
1
Final version
All
Page 2
Visual Architecture
Requirements Definition
Version:
1.0
Date: 2010-09-30
Table of Contents
1. Introduction ........................................................................................................................................................ 4
1.1
1.2
1.3
1.4
Purpose of this document ........................................................................................................................ 4
Intended Audience .................................................................................................................................. 4
Scope ....................................................................................................................................................... 4
Definitions and acronyms ....................................................................................................................... 4
1.4.1 Definitions .................................................................................................................................... 4
1.4.2 Acronyms and abbreviations ........................................................................................................ 4
1.5 References ............................................................................................................................................... 4
2. Requirements Description .................................................................................................................................. 5
2.1
2.2
2.3
2.4
Introduction ............................................................................................................................................. 5
General requirements .............................................................................................................................. 5
Specific requirements – Teacher (architecture designer) part ................................................................. 5
Specific requirements – Student part ...................................................................................................... 5
3. Use Case Models ................................................................................................................................................ 6
3.1 Use case model 1..................................................................................................................................... 6
3.1.1 Use case “Create hardware architecture”...................................................................................... 6
3.1.2 Use case “Write Assembler code” ................................................................................................ 6
3.1.3 Use case “Compile and debug Assembler code” .......................................................................... 7
4. Requirements Definition ..................................................................................................................................... 7
4.1 Requirement Group Definitions .............................................................................................................. 7
4.2 Requirement Sources .............................................................................................................................. 7
4.3 Requirements definitions ........................................................................................................................ 7
5. Future Development ........................................................................................................................................... 8
5.1 General Overview ................................................................................................................................... 8
5.2 Specific group 1 ...................................................................................................................................... 8
5.3 Specific group 2 ...................................................................................................................................... 8
Page 3
Visual Architecture
Requirements Definition
Version:
1.0
Date: 2010-09-30
1.
Introduction
1.1
Purpose of this document
The document is designed to detail the customer requirements. It seeks to define the customer needs, detail them
and finally outline the planed approach to steer the project towards meeting them. It seeks to define the system
boundaries and outline the anticipated possibilities of extension of the proposed solution. It seeks to envision
future extension possibilities for later product versions.
1.2
Intended Audience
The document contains elements that will be used by the:
 Project Team
 Steering group
 Customer
 Any other interested stakeholders
1.3
Scope
The document describes the Visual Architecture project requirements. It begins by providing a general overview
of the project direction then proceeds to describe various use case scenarios and give more descriptive
specifications of highlighted requirements. The document concludes with a vision for the future.
1.4
Definitions and acronyms
1.4.1
Definitions
Keyword
Visual Architecture
Drag-and-drop
Code
1.4.2
Acronyms and abbreviations
Acronym or
abbreviation
ALU
1.5
Definitions
A program designed to create a visual representation of a set of
computer architecture components
An action where the user can move visual components to different
locations on the interface using the mouse
Refers to the simple assembly language supported by the Visual
Architecture program
Definitions
Arithmetic Logic Unit – the basic component of a processor
References
Page 4
Visual Architecture
Requirements Definition
2.
Requirements Description
2.1
Introduction
Version:
1.0
Date: 2010-09-30
The result of the project will be the Visual Architecture program (Eclipse plugin) that will help both teachers
(architecture designers) and students understand how a program affects hardware. Teachers will design the
hardware architecture on which students will work. Students will than write programs that will be compiled and
run on that architecture. During runtime, students will be able to see the components interacting while
performing the actions specified by their programs.
2.2
General requirements
Visual Architecture program is required to enable user to do the following:
 Create arbitrarily hardware architecture from parts like register, ALU, memory and buses
 Write a program for that architecture
 Compile, run and debug the program created
 Create a graphical overview of components interaction while performing the designed program
2.3
Specific requirements – Teacher (architecture designer) part
With the Visual Architecture program, teachers will be able to design hardware architecture using the drag-anddrop principle. To create the preferred architecture, they will need to add low-level hardware components
already predifined; like registers, ALU’s, memory and busses that would connect to the particular hardware they
have visualized. A menu list of the different types of hardware available for inclusion will be provided. Using
this list and the drag-and-drop feature, the teacher will create a design. After the teacher has completed the
hardware architecture design, they will be able to export the information to a file accessible to all. Teacher can
also open and edit old architecture and save the changes.
2.4
Specific requirements – Student part
After the student starts up the Visual Architecture program, they will need to load an existing file that contains
information about some pre-designed hardware architecture. For that architecture, students will be required to
write programs using simple assembler-code. Student should be able to open old code, edit code, make new
code and save his code. There should also be rich text editing help like syntax highlighting and auto-complete.
When program creation is complete, they will be able to compile (build) their code and utilize some debugoptions available in the system. The program would then proceed to take the students on a walk-through their
code. Students will at this point experience a step-by-step graphical depiction of the happenings in their
architecture when their code is run. During the debugging part the lines of code that are currently active should
be highlighted as well as the proper part of architecture on which the code is running. Variables and states of
registers should be shown at least on console.
Page 5
Visual Architecture
Requirements Definition
Version:
1.0
Date: 2010-09-30
3.
Use Case Models
3.1
Use case model 1
3.1.1
Use case “Create hardware architecture”
Initiator:
Teacher
Goal:
The teacher makes a hardware architecture that the students can use.
Main Scenario:
1. Teacher drags some hardware-components on the main field
2. Teacher connects these with other hardware (busses)
3. (S)He saves the architecture
Extensions:
3a If the teacher isn’t happy (s)he can move, delete and add more components.
3b continue at 3
3.1.2
Use case “Write Assembler code”
Initiator:
Student
Goal:
Student writes an assembler program on the given hardware.
Main Scenario:
1. Student opens the given hardware architecture.
2. The student writes assembler code
3. (S)He saves the code
Extensions:
2a1. If the student makes a mistake the IDE recognises it will give some suggestions
a2. The student continues to 3
2b1. The student already started on his code, now he first loads his saved code.
Page 6
Visual Architecture
Requirements Definition
3.1.3
Version:
1.0
Date: 2010-09-30
Use case “Compile and debug Assembler code”
Initiator:
Student/Teacher (whoever want to see the code)
Goal:
Compile the code and see how the hardware deals with this
Main Scenario:
1. Load hardware architecture
2. Load assembler code
3. The user presses the ‘compile’ button
4. The system compiles the code
5. The user uses ‘step-into’ and ‘step-over’ to walk through the code. System shows
what is happening.
6. User closes the program.
Extensions:
1a. The hardware architecture is already loaded: continue at 2
2a. The assembler code is already loaded: continue at 3
4a The code isn’t correct: The system provides info about what was wrong
b. The user corrects the code and continues at 3.
4.
Requirements Definition
4.1
Requirement Group Definitions
Identification
Requirement Group
VAD
Visual architecture design application/process
CIE
Code input and editing application/process
VCR
Visual code running application/process
4.2
Requirement Sources
Source
CTM
4.3
Description
Customer(Marin Orlić from FER)
Rem.
Requirements definitions
Identity
VAD-1
VAD-1.1
VAD-1.2
VAD-1.3
VAD-2
Rem.
Sta
tus
I
I
I
I
D
Prio
rity
1
1
1
1
3
Description
Visual architecture design application/process
Allowing teacher(architecture designer) to assemble graphical
architecture
Providing tools to drag and drop predetermined architecture
parts
Providing tools for connecting parts
Providing means to open, edit and save graphical architecture
Allowing teacher(architecture designer) to make new language
for student and its microcode
Source
CTM
CTM
CTM
CTM
Page 7
Visual Architecture
Requirements Definition
VAD-2.1
VAD-2.2
VAD-3
VAD-3.1
VAD-3.2
VAD-4
D
D
H
H
H
I
3
3
2
2
2
1
CIE-1
CIE-1.1
CIE-1.2
I
I
I
I
1
1
1
CIE-2
CIE-3
D
I
3
1
VCR-1
I
I
1
VCR-1.2.1
VCR-1.2.2
I
H
1
2
VCR-1.3.1
VCR-1.3.2
I
H
1
2
VCR-1.4
VCR-2
VCR-3
I
H
I
1
2
1
CIE-1.3
VCR-1.1
1
1
Version:
1.0
Date: 2010-09-30
Providing tools for writing down language grammar
Providing tools for saving or exporting grammar(language)
Allowing teacher(architecture designer) to design parts
Providing tools for drawing parts
Providing tools for describing parts
Visual architecture should be developed using Eclipse GMF and
EMF
Code input and editing application/process
Allowing student(code runner)to enter code
Providing means to make new, open, edit and save code
Providing tools for code building(compiling)
Providing tools for easier code editing, syntax highlighting,
autocomplete.
Providing means of selecting the language used
Tools for code input and editing should be developed using EMF
and xtext
Visual code running application/process
Allowing student(code runner) to debug code
Providing means of selecting or importing the code for
debugging
Providing tools for simple(step)progressing trough lines of code
Providing tools for advanced(break-point) progressing trough
lines of code
Showing debug information(registers, variables) trough console
Showing advanced debug information (registers, variables) in
special window
Showing visual debug information(graphical architecture)
Allowing student(code runner) to select running architecture
Visual code running part should be developed using EMF and
Java debugger
CTM
CTM
CTM
CTM
CTM
CTM
CIE-1
CIE-1.1
CIE-1.2
CIE-1.3
CIE-2
CIE-3
Requirement status:
I = initial (this requirement has been identified at the beginning of the project),
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = additional (this requirement was introduced during the project course).
5.
Future Development
5.1
General Overview
Since Visual Architecture is quite an ambitious project, there are of course many ways in which it can be
extended.
5.2
Hard-to-implement requirements (on hold or dropped)
Due to the complexity of the task, several requirements have been put on hold or dropped so when one would go
into further project extension, these would be the first to take into consideration.
Visual architecture design application/process:
Page 8
Visual Architecture
Requirements Definition






Version:
1.0
Date: 2010-09-30
Allowing teacher(architecture designer) to make new language for student and its microcode
Providing tools for writing down the language grammar
Providing tools for saving or exporting grammar(language)
Allowing teacher(architecture designer) to design parts
Providing tools for drawing parts
Providing tools for describing parts
Code input and editing application/process
 Providing means of selecting the language used
Visual code running application/process
 Providing tools for advanced(break-point) progressing trough lines of code
 Showing advanced debug information (registers, variables) in special window
 Allowing student(code runner) to select running architecture
5.3
Experimental future features
As with all graphical interfaces, there are many ways in which one can take the technology as an advantage to
present something to the user in a more natural way – to shape the program according to the user, not vice versa.
These are of course features very difficult to implement and would probably be projects on their own, but
interesting none the less.
For Visual Architecture, examples of such features might be:
 hierarchical architectures - designing and examining architectures with a hierarchical graphical
representation; where a student can select the level of abstraction in which he will watch the execution
of his program (for example just the processor and memory or the inside of the processor – which
register is being addressed, what wire is being used)
 program execution animation – the student executing his program on an architecture might see data
animated as if flowing from one location to another through wires; this would appear more natural to
human eye and would be easier to follow changes
Page 9