--- 02/assignment2.tex	2003/12/12 16:00:22	1.8
+++ 02/assignment2.tex	2003/12/13 21:04:39	1.11
@@ -170,7 +170,7 @@
             that while good estimations on use case level can be
             made using this suit, it is not a good thing to try to
             make estimations of the system as a whole only based
-            on this information. 
+            on this information.
   \\ \\ \textbf{Measuring designs}
   \subsection{Measure the class diagram presented in Design 1 using the CK metrics suite presented on the
     lecture.}
@@ -186,15 +186,33 @@
           See appendix c.
     \subsection{Write a short section (up to ½ page) with answers to the following
     questions:}
-        \begin{itemize}
-            \item Which of the metrics could not be computed based on the class
-            diagrams? Why?
-            \item Which of the two systems is more complex? Why?
-        \end{itemize}
-        Svar
+        \subsubsection{Which of the metrics could not be computed based on the class diagrams? Why?}
+              The LCOM (Lack of Cohesion in Methods) metric could
+              not be computed from the class diagram because LCOM metrics
+              are gathered through counting the number of
+              method-pairs that have no attributes in common and
+              then subtract the number of pairs that do have
+              common attributes. This can not be seen when looking
+              at the class diagram so you have to look at the
+              code to compute it. It would probably be quite handy
+              with a tool that computes this metric automatically
+              since it is very time consuming to do by hand.
+        \subsubsection{Which of the two systems is more complex? Why?}
+              Since Design2 has a lower total LCOM value (140 vs
+              93) it is therefore considered more complex.
+              We draw this conclusion from the lecture and slides about CK metrics, a class
+              with low cohesion is ``hard to comprehend, hard to
+              reuse, hard to maintain and constantly effected by
+              change''
         \subsubsection{Which method of gathering metrics - from UML designs or source
         code - is less time consuming?}
-            svar
+          You get a much better overview of the system when
+          looking at the UML design and it is much less
+          time consuming than searching through source code after source code to
+          find inheritance, number of children and so on. Some
+          metrics require going through source code though, so you
+          can not get everything from the UML designs, although it
+          would have been handy if it was possible.
   \section{External product attributes}
     \subsection{Describe how the external product attributes differ from the
     internal ones. Describe the connection between external and