41_Design_Project_Description
docx
keyboard_arrow_up
School
University of Texas *
*We aren’t endorsed by this school
Course
4352
Subject
Industrial Engineering
Date
Jan 9, 2024
Type
docx
Pages
5
Uploaded by HighnessCrab230
SE 4352 4+1 Project Description
Software Architecture
4+1Design Project Description
Spring 2023
Introduction
This project will produce an architectural design for a system / application domain to be
selected by each team. Teams will use the 4+1 Process which has been covered in
class and in the papers provided on eLearning.
The project will be delivered in two phases. Phase one is a requirements gathering
activity where teams describe their problem domain and identify scenarios that describe
operating conditions and operations that occur in their problem domain. Phase two will
have teams complete each of the four views described by the 4+1 process.
Project Documentation
Teams have been provided the following documents in the eLearning project folder.
4+1 Project Deliverables.docx
: A description of the project deliverables
(documents), grading, and delivery for each phase.
4+1 Design Project Description.docx
: This document describing the 4+1 project.
4+1 Design Project Template.docx
: A document that serves as a starting point in
their design. The template document provides an outline defining each of the
document’s sections and the information to be provided in each section, and which
sections are to be completed for each phase.
4+1 Scenario and Tactic Template.docx
: A document that individual team
members use to record their scenarios and implementation required for phase one
and phase two of the project.
4+1 Project Eval Team XX.docx
: A document that lists the team members that
contributed to each project phase. Used to identify team members that did not
contribute to the team’s effort.
Example Projects from previous semesters. Problem domains from these examples
cannot be used by teams this semester.
1
SE 4352 4+1 Project Description
Project Deliverables, Dates, and Grading
Project phase one and two deliverables, delivery dates, and grading criteria is described
in the document ‘
4+1 Design Project Deliverables.docx’
.
A Word on Professionalism
Professionalism
: The conduct, aims, or qualities that characterize or mark a profession
or a professional person.
The overriding desired quality of your team’s deliverables should be a professional
attention
to both the scope of detail put into the design, and the presentation of the
materials in an organized and intelligible manner. Ask yourself:
Would I feel comfortable
presenting this material in a professional setting?
Project Problem Domain Selection
Each team is responsible for selecting their project’s problem domain. First off, any type
of ecommerce application will not be allowed.
There have been too many examples
provided in class based on that domain. However, if you have an idea that you think
may be too similar to ecommerce to consider, feel free to ask me about it.
Also, any domain that mirrors the Example Projects will not be allowed.
The success in the project will be largely measured by the size and complexity of the
scenarios, UML and other models delivered in their documents. Detailed and complex
models demonstrate the effort that teams placed into their analysis and design.
Select a broad and complex project domain e.g. mars rover, driverless vehicle, or
something equally large and complex. Your scenarios and ultimate design should
broadly
cover several (if not all) aspects of the selected domain / system. For example,
the mars rover (vehicle) is only part of a much larger system that includes platform,
sensors and instruments, sensor data capture, data and telemetry data relay through
mars orbiting satellites, earth-side receiving antenna complex, recording and archiving
of received data, command and control of the rover, and whatever teams can think of. A
large project domain offers many low hanging, easy to identify scenarios. During the
design phase, a large project domain will provide many different services that will be
easy to identify and model.
A delivery that appears to have been produced by a team motivated to produce quality
work goes a long way towards a great project grade. The motivation to produce quality
2
SE 4352 4+1 Project Description
software is something that employers look for in their development teams and I do not
see why this course should be any different.
Phase One
Phase one is concerned with the understanding the problem domain, basic description
of the customer’s goals, and capturing a number of scenarios.
In terms of deliverables, the sections marked as Phase One in the ‘
4+1 Design Project
Template.docx
’ document are to be completed and submitted. Individual team
members are to complete N scenario and tactic documents for submission. Specific
requirements and method of project submission is described in the project deliverables
document.
Team members should work together completing the project description and identifying
scenarios. The project description will be graded as a team effort and individual
scenarios will be graded by team member as described in the project deliverables
document.
Desired Scenario Topics
Each scenario will describe a distinct feature of the problem domain. Ideally, this feature
will identify a fault or operating condition that the system’s design needs to address e.g.
a component failure or performance issue. However, it would be unreasonable to expect
teams to identify 20-25 scenarios of this nature
. With this in mind, scenarios can also
describe important workflows to be implemented by the system’s design. Each workflow
must be distinct i.e. no variations of the same basic workflow.
Each team member is expected to submit distinct scenarios.
“Distinct” means that each
scenario should describe a meaningful and distinct goal / problem to be addressed by
the system. Multiple team members cannot submit the same scenario. Teams are
encouraged to identify scenarios as a group, then assigned to and completed by
individual members.
Each scenario is to be documented with the ‘
4+1 Scenario and Tactic Template.docx
’
document provided on eLearning.
Phase Two
Phase two is concerned with the development of a system’s design using the 4+1
process as described in class and in the papers provided on eLearning.
3
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help
SE 4352 4+1 Project Description
In terms of deliverables, the sections marked as Phase One and Two in the ‘
4+1
Design Project Template.docx
’ document are to be completed and submitted.
Individual team members are to select and complete N scenario and tactic documents
from their phase one submission. Specific requirements and method of project
submission is described in the project deliverables document (
4+1 Design Project
Deliverables.docx
).
The phase two Design Project Template document is a continuation of the document
submitted for phase one. Teams will complete the “Phase Two” sections of the 4+1
Design Project Template document, along with any remaining Phase One sections that
may have been overlooked.
The scenario and tactic documents will be completed by individual team members.
Each member will implement N of their phase one scenarios submitted for phase one as
software designs using the sections marked ‘Phase Two’.
UML Modeling
The level of detail in the UML diagrams describing each of the four views in the
Template Document will be graded on a team basis. The diagrams in the individual
Architectural Tactics documents will be graded on an individual basis.
The level of detail in the UML diagrams describing each of the four views is important.
Class and component diagrams for the logical view
Class and component diagrams for the process view.
Component and deployment diagrams for the physical view.
Note
: The quality attribute being addressed is used to select the design pattern. The
selected patterns suggest the classes and component that implement the pattern in the
context of the team’s problem domain.
Note
: The 4+1 workflow uses components to encapsulate services provided by the
design. Multiple services can be combined into a Processes (executables) using
Components with the <<process>> stereotype. Processes are deployed (placed) in
Processors (nodes) using UML deployment diagrams.
Continuity of Design
The design should be consistent across all views, control strategies, and individual
scenario designs. For example, the components / classes in the logical views should be
carried over to the dynamic, process, and physical views (where appropriate).
Components identified in the global 4+1 design must be carried into individual scenario
and tactic designs produced by each team member.
4
SE 4352 4+1 Project Description
The global 4+1 design must include all four views as organized in the
4+1 Design
Project Template
document.
The overall design must clearly demonstrate the use of both the client-server and
the data-flow architectural patterns to be presented during our meeting.
The overall design must clearly demonstrate the use of distinct architectural tactics /
design patterns. Each member will be responsible for N patterns in their scenario
designs. The use of their chosen tactic will be explained by each individual member
during the team’s project presentation.
Use of Astah UML Editor
An important aspect of practicing software engineering is the use of a design notation to
express your architectural and component designs. Industry and academics have
settled on UML as the de facto standard software notation. For this reason teams will
use UML diagrams to describe the various views where appropriate required by the 4+1
process.
It is required
that teams use the Astah UML editor to produce these diagrams for their
Phase Two materials. (UML diagrams are not needed for phase one deliveries.) Failure
to use Astah will result in points lost. Designs and scenarios not documented using
clean and clear (professional) UML notation will result in significant loss of project
points. Use the diagrams presented in the slides as the baseline for what is expected.
For example, the use of a UML component to represent a Process including the nested
service classes and interfaces. A video tutorial on obtaining and using Astah can be
found
https://youtu.be/Yz-euQYZZWY
. A sample Astah project (Sample ECommerce
4+1 Views.asta) has been provided with the project materials.
5