ENSE 622/ENPM 642 Term Project

Due: 7.00 pm, May 10. This is the last day of class. No extensions!


Problem Statement

The purpose of the term project will be to create a frontend system-level representation for an engineering system of your choice.

To the extent possible, the system-level representation should be as technology independent as possible -- that is, focus on development of models for required functionality, system architecture, and mappings of functionality to architecture. Your project should set the stage for an implementation downstream that could be in software, hardware, biology, chemistry, or any combination of these entities.

I suggest that groups of two students stick to development of a single engineering system.


Choosing a Project ...

You can find the best projects from recent years in the folders of support material distributed in class.

I am particularly interested in seeing things that have not been tried in previous semesters. As I mentioned in class, my suggestions (and they are only that ... suggestions) are:

Suitable problem domains could include: buildings, roadways, railways, hybrid transportation systems (e.g., combinations of rail and bus).

If you think you have something, let's talk about it and I'll try to help.


Things to Do

I realise that this semester we are dealing with a wide variety of project types and, as such, I want to be flexible. Something that works really well for one project may be completely inappropriate for another.

Here is a suggested list of topics you might like to include in your project:

  1. Project Description.
    Projects should begin with an easy-to-read description of what the project is about.

  2. Goals and Scenarios.
    Briefly summarize the goals and associated scenarios for this problem domain.

  3. Initial Use Case Modeling.
    Identify the actors and system boundary? Develop set of "textual" use cases for this problem domain.

    For each use case, identify the actors, flow of events for normal and alternative courses of action, and pre- and post-conditions (if they exist).

    Develop activity diagrams showing the sequence of tasks that are accomplished in the execution of individual scenarios.

    Also develop sequences of message passing among objects during the execution of these scenarios.

  4. Organize the Use Cases.
    Organize the use cases into a use case diagram. Indicate <<extends>> and <<uses>> relationships between use cases, if they exist.

    If your project has more than about 10 use cases, think about creating a hierarchy of use case diagrams.

  5. Requirements.
    Develop a set of system and test requirements for this problem domain. Identify the source (i.e., "goal" or "use case") of each requirement (or group of requirements).

  6. Organize Requirements.
    Organize the requirements into layers of development -- each layer should have a well-defined purpose.

  7. Model of System Behavior.
    Create a hierarchy of tasks for "what the system will do."

  8. Model(s) of System Structure.
    Identify the key components and subsystems that are needed for the system structure.

    Organize the components and subsystems into a composition hierarchy diagram and/or component schematic (if you think that is appropriate).

    Show multiplicities when they exist.

  9. Architecture-Level (logical) Design.
    Map the model of behavior onto the system structure, and show how the various logical scenarios will be handled by the system (i.e., what is the pathway of calculations and messages for each type of computation).

    I'm envisioning that one or more collaboration, statechart and/or composite-structure diagrams will be appropriate for this task.

    Show how the components will interface with each other, and the external world. Consider:

    Explain how the architecture-level design is constrained by the selection of standards and adoption of technologies.

  10. Use Case/Component Task Interaction Matrix.
    Develop a use case/component task interaction matrix.

  11. Traceability.
    Develop traceability matrices to show:

  12. Clustering and Modular Design
    Some projects will be amenable to improvement via clustering and modular design with design structure matrices.

    One possibility would be to implement the concepts explained in "Modularity in Design of Products and Systems" by Huang and Kusiak, 1998.

  13. Measures of Effectiveness.
    What are the measures of effectiveness for system assessment at the logical and physical stages of design? How are they evaluated? And what are the difficulties in the evaluation?

  14. Trade-Off Analysis.
    Formulate and, if possible, conduct a trade-off analysis for "design options" versus "measures of effectiveness" at the logical stage of design.

    One parameter of your trade-off anaysis should be estimates of cost. I expect that the remaining parameters will depend on the nature problem you are addressing -- for example, features, performance, reliability ... etc.

    If system cost depends on the choice of technology, then think about conducting the trade-off analysis using bounds [ min, max ] on cost associated with available components and technologies.

    Use either CPLEX or the optimization procedures in Excel.

  15. Conclusions and Future Work.
    Wrap things up:

For the UML I sugest that you use either MS Visio or ArgoUML.


Brief Presentation

Aim for 15 minutes (i.e., no more than 10 slides).
Focus on the problem statement, and "what you are trying to do that's new..."

If you are at a remote site then your can simply e-mail me your presentation.


What to Hand In

Hand in a hardcopy of your final report and presentation (if need be, it can be revised to account for constructive feedback) in an appropriate format (e.g., MS word, pdf, Powerpoint).


Developed in March 2010 by Mark Austin
Last modified: March 8, 2010.
Copyright © 2010, Institute for Systems Research, University of Maryland