Book a Demo

Author Topic: How to structure a project when using packages  (Read 14577 times)

MichaelHanson

  • EA User
  • **
  • Posts: 31
  • Karma: +0/-0
  • EA is the best
    • View Profile
Re: How to structure a project when using packages
« Reply #15 on: June 06, 2005, 10:06:47 am »
Peter

I agree with Mikkel in that different Views will probably have different structures.

As I said before I structure my top level views according to the phases of the MSF.  However within these View containers I will use packages in different ways.  For example in the Planning phase of MSF I would be creating both Logical and Physical designs.  In the early stages of the Logical design for a large project I generally divide my system into Subsystems and create a package for each.  As I am now working predominantly with the .NET Framework, these typically become separate namespaces, which I usually carry over to the Physical design.  On a smaller project, I would do the same as Mikkel and use packages for component boudaries.

Hope this helps
Mike
Mike Hanson
Microsoft Technology Specialist

davisford

  • EA User
  • **
  • Posts: 63
  • Karma: +0/-0
    • View Profile
Re: How to structure a project when using packages
« Reply #16 on: June 06, 2005, 04:45:53 pm »
I think the answer is -- it depends.  Kruchten defines the 4+1 views, which are covered somewhat in the default EA views.  There are other "Views" that may be useful for your process, or if you choose to follow someone else's definition of a process, they may have additional views.  

I have found that how you organize your model depends on 4 major factors:

1) what "views" are important for you -- tied to some kind of design process
2) code generation -- if you use it, organize things wisely...especially if the code uses packages as namespace
3) documentation generation -- if you use it, also organize things wisely, because this can really help you not have to completely reorganize everything in order to generate good documentation out of the model.
4) Version Control strategy -- if you are going to have multiple people work on it...you need to organize things wisely to allow it.

I think it takes time, learning/experience to get good at this and have a good vision for how to organize it and break up the work.  Initially, a lot of stumbling occurs and bad organization, etc., but as you continue to work -- things get more clear, and a cleaner picture evolves.  I would definitely keep those four things in mind, though, as they tend to be some of the bigger driving factors.