Student Course Registration System

COSEML Based

DESIGN REPORT

CENG 551 Fall 2001

December

DecemberD xx, 20XX

Ayşe Güzel

Mehmet Güçlü

Computer Engineering Department

Middle East Technical University

Student Course Registration System

Design Report

date

{Minimal wording – emphasize the graphical model}

1.Introduction {one or two sentences}

2.System Overview

  • deployment diagram if necesary,
  • COSEML main diagram, and
  • Use Case diagrams {actors and abstractions. Use the Package/ Function/ Data abstractions instead of ovals: }

3.Design Considerations {probably nothing here}

{a. Assumptions and Dependenciesb. general constraints

c. Goals and Guidelinesd. Development Methods}

4.Architectural Strategies {probably nothing here}

5.System Architecture {detailed COSEML diagrams for different aspects. All connectors should be drawn in this section (may be in different diagrams)}

6.Policies and Tactics {probably nothing here}

7.Detailed System Design

7.1 collaboration diagrams using components and interfaces instead of objects; showing message and event connections

7.2 method specifications: input parameters, output parameters, what services are required (outgoing messages – method calls)

7.3 control specifications {for control abstractions: state machines – probably nothing here}

8.Glossary {probably nothing here}

9.References {probably nothing here}

10. Overall metrics form {given in my web page before - attached}

11. Metrics table for every component {attached}

note: {text written in curly braces are comments – they should not appear in your reports as written here. You should replace them with your values. Titles should be present, even if nothing is written under them. Some of the items like ‘deployment diagram’ may not be necessary, depending on your project. If a new title is required, try to insert it at the most approproate position}

Overall Metrics Form for COSEML based models - - Do not include the documentation effort - -

Number of people in the team:
Total person-hours:
Member 1 name: / Person hours:
Member 2 name: / Person-hours:
Total person-hours spent for modification:
person-hours for an average maintanance (correction):
Complexity of the Model:
Number of boxes (total- abstractions, components, interfaces..):
Number of Components:
Number of Interfaces:
Number of Connectors:
Number of event links:
Number of method links:
Number of methods:
Average number of methods per component:
Average number of input events per component:
Average number of interfaces per component:
Average number of methods per interface:
Maximum depth of the composition tree:
Maximum width of the composition tree:
Average NOC (Number of Children in the composition tree):
Average DCT *(Depth of composition tree):
Average CBC* (coupling = cardinality of methods called from outside):
Average RFC (Response for a Component):
Average Mean LCOM* (mean values averaged for Lack of Cohesion in Methods):
Please give a grade (5: strongly agree; 1: strongly disagree) / 1..5
It was easy to model your problem using COSEML:
Your model is an understandable representation of the problem:
  • RFC: (Response for a Component) number of local methods + cardinality of called methods as a response to an incoming message (function call)
  • CBC: (Coupling between Components) class A calls a method in class B: A has a CBO of 1, B has a CBO of 0.
  • LCOM: (Lack of Cohesion between Methods) number of method pairs not sharing attributes – number of pairs sharing attributes.
  • DCT: (Depth of Composition Tree) number of parents on the path from a node to the root

Metrics Table

Component Name / # of Methods / # of in. events / # of interfaces / NOC / DCT / CBC / RFC / LCOM
Student / 6 / 0 / 2 / 2 / 0 / 8 / 15 / 3.4